The Rumors of my Demise

Ever since Microsoft unveiled the Windows Runtime (or WinRT) interface and declared HTML and JavaScript as the preferred platform for creating Windows applications, many .NET developers have felt somewhat slighted and devalued.  After having invested (in some cases) 13 years to the development platform, it appeared Microsoft was about to make a sea-change which negates the investment made in becoming .NET experts.  So, is .NET going away and do we need to retool/train for another technology?

The short answer to the question “nope”.  At the Microsoft Build conference this year, at the keynote presentation on day 2, Microsoft actually apologized for the confusion they created.  In a subsequent blog post, Microsoft VP Soma Somasegar stated: “Given the huge impact that .NET has for companies, including both expertise and assets created while developing their applications, and given Microsoft’s recent focus on talking about the newest platforms and increased openness of those platforms, it makes sense that many of you have been asking Microsoft about our commitment to .NET.  So, let me be very clear: Microsoft is fully committed to helping you use .NET in your existing applications, as well as being fully committed to helping you extend those applications and building new ones to the emerging patterns users are demanding.  This includes (but is certainly not limited to) your desktop applications and your client/server applications running on-premises.”

Reading between the lines in that statement, it sure sounds as if the emphasis on .NET technologies will slowly shift (evolve?) in the coming years.  The reality is, however, that successful technologies sometimes take decades or longer to fade away. Most people would be shocked at how much of the world still runs on RPG, COBOL, FORTRAN, C, and C++ – all languages that ostensibly became obsolete decades ago. Software written in these languages runs on mainframes and minicomputers (also obsolete decades ago) as well as more modern hardware in some cases. Of course in reality mainframes and minicomputers are still manufactured, so perhaps they aren’t technically “obsolete” except in our minds.

It is reasonable to assume that .NET and Windows will follow those older languages and operating systems into the mists of time, but the truth is that such a thing will take years to occur.  I think it is critical to understand that point, because if you’ve built and bet your career on .NET it is good to know that nothing is really forcing you to give it up. Although your chosen technology is already losing (or has lost) its trendiness, and will eventually become rare and then increasingly obscure, it is a pretty safe bet that you’ll always have work. Even better, odds are good that your skills will become sharply more valuable over time as knowledgeable .NET resources become rare.  Doubt that?  Ask any COBOL programmer from the Y2K days.

So, how will this fading of the .NET stack occur?  To answer that question I will first divide the use of the platform into its two base constituencies: personal devices and servers.

When considering a personal device (and by that, I mean the traditional desktop, laptops, tablets and smart phones), I feel compelled to divide the category again into personal and business applications.  The reason for doing so is that there is a distinct economic difference between these types of applications.  So we will consider these individually.

When considering personal applications, development tends to be driven by a set of economic factors that determine whether the creation of a native version of any given app makes sense for every individual platform.  If the indicators suggest that your app is suited for a specific platform, in this scenario languages like Objective C, Java, and .NET all have a bright future.  That is to say, each of these languages are of specific use when a personal application is intended for a single target only as each language is intended for a single platform.  You cannot natively deploy an Objective C application on a Windows device.

From a device manufacturer’s viewpoint, this is the best of all worlds.  Individual platform development through native-language applications effectively locks a consumer into an ecosystem their product targets.  The problem is, however, that while it makes perfect economic sense the manufacturers often lock developers out of key areas of hardware control, making it all but impossible to write native applications which truly take full advantage of the hardware any given device presents.

It is only when a developer targets multiple platforms for their application that cross-platform language and technologies begin to make sense.  Rather than incur costs to develop native-language apps for each platform, it makes sense economically to “write once and tweak everywhere”.  JavaScript will likely become a major player in this space (today, at any rate), but that assume that Apple, Google, and Microsoft work together to standardize support for the language, which in turn undermines their existing proprietary development tooling. Economically, none of these companies want every app on the planet to run equally well on every device because it eliminates most of the competitive advantage their hardware may have over another device.  At odds with that mindset, it would seem that Microsoft really is doing their best to make sure JavaScript runs optimally on Windows 8 in all its flavors.  Doesn’t mean anyone else is doing so, but then any revolution starts with a single shot.

Business apps, on the other hand, are driven by the concept of the natural monopoly. Simply put, any software development business wants their product to be written and maintained as cheaply as possible – not “cheaply” as in quality, but “cheaply” as in cost-effective. Rewriting the same app several times to get a “native experience” on numerous operating systems does not support that approach.  Put a different way, to engage as many end users as possible, a development house has to put their product in front of as many clients as they can.  Impossible to do when development is in a single language targeted for a single platform.

This leaves us with the notion that in order to be successful businesses won’t choose one platform in the traditional sense, but rather will choose a more abstract platform like JavaScript.  Today this is pretty hard because of differences between Java virtual machines running on various platforms, from inconsistent support across platforms for popular open-source JavaScript libraries and by JavaScript itself.  Because of this, building a cross-platform JavaScript app probably costs more than building the same app in .NET or some other more mature/consistent (and narrowly-cast) technology.

The economics of scale is the deciding factor between personal and business applications, and hence the difference between how apps targeting each can be written.  At the end of the day, each company is faced with the same 3 ugly choices regarding application development: write and maintain every application at least 3 times (Windows, iOS and Android); build and maintain in a cross-platform tool like JavaScript (and possibly sacrificing the benefits of any given platform for having a larger install base); or selecting a single platform.  The first choice is obviously the most expensive one, and as such it is only attractive to the largest of software development houses.  Most companies find themselves forced into a choice between options 2 and 3.

Servers are a simpler economic model than personal devices.  Most servers today leverage either .NET or Java, so the platform choice is simpler.  While there are a lot of other server-based code in use (again with the COBOL, RPG, FORTRAN, and other legacy languages), practically no one is actively developing in those languages – maintaining, yes, but not new development.

Although JavaScript is represented on the server via tools like NODE.JS, it doesn’t seem likely any business entity would be looking at moving away from native platform tools anytime soon.  I am not sure that an argument can be made for directly supporting a client/server common language approach to development because each class – client and server – serves a different need.  And as fundamentally different platforms, it does not make sense to write code in a non-specific way when there is a client/server contract in play.  Because of the wealth of moving parts in any server-based application (or, at any rate, the potential of a growing number of moving parts), native language applications are almost a necessity on the server while cross-platform languages seem like a necessity for the client.

Back in the 90’s I worked in Visual Basic.  Before that, I spent time in Turbo Pascal and Dbase, and before that in REXX on a mainframe.  When .NET was introduced, I jumped on the bandwagon and realigned my skills with the new platform.  And today is not different – I am retooling for the cross-platform world.  Does that mean that my investment in learning all these disparate technologies was a waste or that I will no longer have an opportunity to work in these languages?  Apart from REXX and maybe Visual Basic, the short answer is no. 

While it is interesting that Microsoft issued an apology about the confusion it created, it is also important to note that they did not turn the Titanic around.  There were no admissions of guilt or last minute reprieves from the governor regarding the demise of technologies like Silverlight or Windows Forms or even Windows Presentation Foundation.  It is obvious to one and all that while .NET remains a highly desirable and necessary platform for server-side development, on the client Microsoft is clearly aligning themselves with the cross-platform camp.  Make no mistake, it is not a slight against the people who made .NET a success, but rather an attempt to remain relevant in a changing world.  In that respect, it is not much different from what they did with the introduction of .NET. 

Evolve or die.  It is that simple, and if you don’t believe me, just ask any dinosaur you meet.