Friday, September 17, 2010

Is .NET On Its Way Out?

I can't help but notice that the frequency of C# (or .NET in general) questions on Stack Overflow is dwindling.  And the questions which are asked tend to be asking how to use one of Microsoft's pluggable widgets to do some specific task, usually exposing entry level code with no understanding of what the code is doing short of what the widget's instructions said to do.

It's a little unsettling, to tell the truth.  And it makes me wonder if the C# enterprise developer's days are numbered.  Java still seems to be going strong in the enterprise, so it's not much of a jump to that.  But to be honest I really do love .NET and where it's gone in the past few years, but it seems like Microsoft is steering it back to the old days and enterprise developers just aren't going to follow it there.

I've been thinking about this for a while, actually.  My own personal view on the timeline of Microsoft development may be skewed by my own experiences, both positive and negative, but this is just how I see it.  (Consider that a disclaimer, and if you have any insight contrary to my following assessment then please present it.)

Back in the day (pre-.NET), "Microsoft development" generally consisted of VB programmers, fluent in and ins and outs of COM and ActiveX and other such things, rapidly developing applications.  Whether it was in Access, ASP, or the more proper flavors of VB (do you remember VB5?  blech).  This wasn't really "enterprise development" so much as it was rapid application development performed sometimes in enterprise environments (or start-ups, or other small environments, etc.).

"Enterprise development" was going strong, but didn't get a lot of press.  C++ developers are a reclusive breed, and they don't tend to hang certifications on their cubicle walls to validate their skills.  Their software spoke for itself, and the enterprises in which they worked listened.  (Sure, that's painting a general picture.  Bear with me, this is just an allegory.)

Along came .NET, and things began to change.  Microsoft was ambitious with this project, and rightly so.  They wanted to "unify" things, in no small part because Java was already doing that.  Java was at the time nowhere near the enterprise language that it is now (remember "applets"? do they still have those?), but it was a clear and present threat to Microsoft's hold on the developer market.  After all, Microsoft sells the widgets, the tools that use those widgets, and the classes that teach those tools.  They wanted to protect that.

I remember the early days of .NET when C# was the cool new kid on the block, and I remember hordes of VB6 developers up in arms demanding that VB remain strong in the emerging .NET ecosystem.  That sort of made me wonder at the time... What kind of developer ties himself to a specific language?  Back then my background was almost purely academic (university), and different languages meant little to me beyond the syntactic expression of the core concepts.  VB, C#, it made no difference to me.  But the framework, now that was cool.

Continue forward through the life of .NET.  Microsoft's own people loved it, and treated it as best they could.  1.0, 1.1, 2.0, 3.0, 3.5... each new version presented wondrous new ways to apply design principles.  Though, to be honest, I really didn't like the explosion of web controls and providers in 2.0, and I guess that can be seen as a foreshadow for what I'm discussing here.  The web controls and providers were "pluggable widgets" where Microsoft was continuing its previous ways of trying to remove the developer from the equation.  Remember their business model all along.  They're not interested in helping you make better software, they're interested in helping your manager make the software himself.  Or have his secretary do it.

But .NET seemed to be changing this.  Enterprises were using it as a serious development platform, and it accommodated them well.  3.0 and 3.5 really moved it forward, and 4.0 continues to push it.  New forms of expressiveness, easier ways to apply known design patterns and build robust, maintainable code.  Sure, there was still room for the rapid application developers, the widgets still existed.  But the environment was much more than that.

And open source projects like Mono get into the game and have made their own enhancements and improvements.  Overall the community contributions have grown over the years, and some cool stuff has come out of it.  IronPython and IronRuby just to name a couple.

But what's going on now?  Have you noticed that some of Microsoft's own people have been jumping ship?  IronRuby has been pretty much abandoned by its overlords, though I'm still holding out hope that the open source community will pick up that slack.  (This might be something for the Code Dojo to look into, actually.)  Microsoft, and by extension Visual Studio (which is a damn good IDE, for all your IDE haters out there), have recently been moving back to the pluggable widget model.

Why?  I guess it's their business model, and that's their right.  But the effect I'm beginning to see is that they're being taken less seriously in enterprise development.  Sure, there are plenty of enterprises who have bought in to Microsoft's widget mentality, and don't see a difference between rapid applications and enterprise development.  But there is real development going on out there, and it's being done by real developers.  Microsoft's own people know this, and some of them are sticking with it despite Microsoft's turn in the other direction.

To visualize this, I tend to think of enterprise development and Microsoft development as two parallel lines.  Those lines have converged more and more throughout the life of .NET.  But it appears that they're once again pulling away from one another.  And there is no shortage of developers from the Microsoft line who have jumped over to the enterprise line.

It occurs to me that developers who are enjoying the enterprise line would do well to rise above the Microsoft stack and become more tool-agnostic in their development.  Otherwise, we may easily find ourselves in the same boat as the VB programmers who were called to arms ten years ago to protect their invested skill sets.

1 comment: