Whither .NET?
Those of you who know me well will already know that I have been saying since the first views of .NET went public that my opinion is that .NET will be the straw that breaks the camel’s back. In other words, I think that Microsoft has got the whole .NET thing so badly wrong that, in the long run, it could actually bring the company down. Interestingly Craig Bailey has posted something only the other day that takes a different slant on the question but which, I think, makes some extremely telling points. Check out his article right here:
http://craigbailey.blogspot.com/2005/07/net-return-on-complexity-roc.html
But back to my thoughts. Why do I think that Microsoft, a notoriously good marketing company, has got this one wrong? Well here, in a single sentence, is my reason.
There is simply no defensible case for switching from an existing development platform to .NET!
Now let me expand on this a little. First I must stress that I am totally impressed by and thoroughly in favor of ASP .NET! This is the tool for which web developers have been longing since commercial internet applications first began to be constructed. It is long overdue, and only looks like it is going to get better with time. So I am totally behind the ASP .NET initiative. But, alas, as for the rest of .NET, it is ill-conceived, poorly implemented and adds little or no real value to the existing development tools and environments. Consider this from the view of an existing application developer – why should such a person change their development environment and tools? Seems to me that there are three “imperatives” which drive such a change:
· Technical Imperative (the most important!)
· Infrastructure Imperative (often a major limitation)
· Business Imperative (the least important!)
Let’s examine each in turn.
Technical Imperative
Basically this states that the new environment will permit you to tackle tasks that, in your current development environment you simply cannot do. This is why I am so enthused about ASP .NET - it definitely has the technical imperative going for it.
However, for the rest of .NET the case is totally different! What can you do in .NET that you cannot already do in your current development environment?
Note that I am not saying that .NET cannot do some things better – of course it can (but by the same token it also does some things worse!!!). The key question here is what it can do that you cannot do with your current development tools? If there is something (and I don’t know what your chosen development environment is) then the second question is “Does it matter?”.
My take on this is that organizations and people choose tools that are appropriate to their needs. (If it helps to use an analogy consider this: Does an electrician really need a automobile hub-puller? Probably not, but an auto-mechanic…?). By definition, therefore, anyone already developing software has the appropriate tools at hand and really does not need anything else! So unless there is an overriding technical issue that has hampered them in the past and which .NET allows them to solve, they have no reason to switch.
My problem with .NET (in this context) is that I do not see anything that could possibly be construed as “new capabilities”. All I see is different ways of doing things that we can do already. Therefore it fails on the most important of the three imperatives.
Infrastructure Imperative
This states that an organization has been limited in its choice of development environment by the need to operate and support an existing hardware infrastructure. The imperative comes into play when, for some other reason than software development, that infrastructure is changed or upgraded so that environments that could not hitherto be supported can now be used. In other words, the driver here is the fact that something external to the software process has driven the change.
The problem that confronts .NET is that its adoption typically REQUIRES an infrastructure change (i.e. hardware upgrade). So instead of being a concomitant option that becomes available when the change occurs for other (usually economic) reasons it’s adoption necessitates the change and therefore has direct long term cost implications.
When taken in conjunction with the technical imperative above the combination is potentially ruinous.
Business Imperative
Now this is the drive on which Microsoft has, to date, based the entire .NET strategy (and in fact the entire corporate farm). This imperative, simply put, relies on fear and (technical) ignorance. The basis for adopting .NET has nothing whatever to do with it’s technical merits or requirements but it is done simply because of the perception that “competitors” are doing so!
It is significant that most of Microsoft’s efforts at marketing .NET are not directed at technical personnel but at “Management” – particularly “Senior Management”. This reflects, I believe, the fact that they realized early on that they could not actually meet either of the imperatives for Technology or Infrastructure and that the only way to promote widespread adoption of their flagship new product was to rely on this approach.
To date the take up has (reportedly) been “disappointing” and “slower than we had hoped”. The main adopters seem, on the whole, to have been large organizations where the non-technical approach works best. In smaller organizations, where decision makers are closer to the actual technology, I suspect that the take-up has been far less than most of us even realize.
How can .NET hurt Microsoft?
The key question is why did Microsoft bother with .NET? I believe that the answer lies in the business model for the corporation as a whole. For many years Microsoft relied on the ‘Upgrade’ model for their revenue. A new operating system was produced every two to three years and people rushed out in droves to buy it (remember the launch of Windows 95?). Microsoft Office was (and still is) the best selling office package. Upgrades came out and people upgraded. It has been estimated that Office Upgrades alone accounted for well over half (and I have seen estimates as high as 80%) of Microsoft’s revenue in the late 1990’s.
The problem with this model is, of course, that it relies on people (and organizations) continuing to upgrade their software. As products reach maturity there is a limit to the number of ‘necessary’ new features that people will be willing to pay for – either in the Operating System, or in the Applications that they use. This was, I am sure, well understood by Microsoft who had to be aware that there was going to come a time when people simply would not bother to upgrade any more. Latterly of course, the rise of the Open Source initiatives has threatened both the Office application and even Microsoft’s flagship database SQL Server (which has not even been updated for 5 years now!) – why else the scramble to release first “MSDE” and now “SQL Server 2005 Express”?
(Just for the record, I am writing this in Word 2000 running on a Windows 2000 operating system! Even though I have Windows XP, Windows 2003, Office XP and Office 2003, there is nothing new in any of them that I actually need. Not only did I have some compatibility issues (especially PowerPoint) when I tried newer versions, but I am already both familiar and comfortable with the “2000” versions – so why bother to upgrade?)
So where could Microsoft turn for a significant new source of revenue? The answer they chose to adopt was, of course, to develop a comprehensive software development environment that would require investment to adopt and which, once adopted, would not be easy to get out of. We are looking at the result in .NET!
Of course .NET is still in its infancy – the next release (Whidbey) promises more and newer things but, significantly, makes no commitment to maintain backward compatibility with the current version of things. Why? The official answer is so as not to constrain the development of the framework and the tools. The reality is, I suspect, that as with most new things the first versions were simply wrong. Now they have to be fixed and correcting those fundamental flaws whilst maintaining backward compatibility has proven to be impossible (else, presumably, they would be trumpeting the fact!)
In the real world I believe that most software development is still done by small organizations (often only one or two developers) and unless Microsoft can convince this sector of development world in general to adopt .NET I do not see where the revenue to replace the ever decreasing stream of upgrade funds will come from.
This is why I think that, in the medium to long term, Microsoft could be seriously hurt by their commitment to .NET to the exclusion of almost every other product in their range! I hope the crash won’t be too disastrous because Microsoft have been, on the whole, good for the industry. However, I still believe that the developer world is actually smarter than people at Microsoft give them credit for and that Microsoft are heading for a crash that will arrive sooner rather than later.