...The Disaster Known As Visual Basic

It must be hard to be a humble German rail clerk and find yourself blamed for the First World War. A principal cause of that disaster was the inflexibility of German and Russian railway timetables. All you were doing was plotting the easiest way to get from Potsdam to Frankfurt and, hey! – you’re responsible for the whole damn’ mess. Life’s a bitch as they say.

So which humble rail clerk in Microsoft was responsible for the Visual Basic disaster? Let’s not mince words here – it is a disaster. We’ll come to the figures shortly, but let’s go through the fundamentals first.

Some time in the late ‘90s, Microsoft started to panic about Java. It was the second such attack of the vapours that Microsoft had had, the first being the realization that the Internet had happened and that Microsoft wasn’t in charge. In response to this, Microsoft re-engineered the company to face the new threat. Some things worked (Internet Explorer) and some absolutely sucked – such as the Active Desktop.

Anyway, something had to be done about Java. First Microsoft tried to ‘borrow’ it from Sun, with the intention of neglecting to return it. Sun saw that one coming and told Microsoft where to get off, though a fat lot of good it did the now setting Sun. And so Microsoft decided to invent its own Java - C#.

It’s turned out that Java wasn’t much of a threat to Microsoft at all. Java on the desktop is non-existent – personally, I don’t even have the Java runtime installed. On the Internet, you now occasionally come across a Java ‘applet’, typically written by a university professor with time on his hands. Where Java really sits is between a database (Oracle) and a Unix web server, providing the business logic that drives e-commerce. It’s a decent business to be in, but it isn’t huge: It seems that Sun got around $140 million from its Enterprise Java Systems last year (if a ‘subscriber’ is equivalent to a ‘license’).

Having decided that Something Must Be Done about Java, Microsoft set about building a class library that would support C#. This is the .NET framework. The other thing it did was build a managed memory system – the Common Language Runtime or CLR – and this is where things get interesting.

The problem was (and still is, believe me) that Microsoft already had a managed memory system, COM. COM and the CLR have different memory management models. The CLR works on a ‘mark-and-sweep’ model while COM works on reference counting. The key difference is that when the number of things referencing some COM memory goes to zero, it commits suicide and disappears. This effect is given the rather sinister name ‘deterministic finalization’. In contrast, with a freed CLR object, you don’t know when it will disappear, it just vanishes at some future time.

For most people, most of the time, this distinction isn’t important. But it is if your COM world application depends on deterministic finalization (and some big ones do). It’s also important in that it breaks the compatibility between COM and CLR. In this respect, COM and the CLR are like oil and water; they don’t mix.

But once you’ve broken the compatibility between the two, then the trains are starting to move.

The deterministic finalization business is so important that Microsoft (unusually) described the technical reasons for its decision - see HERE (and also the Classic VB website).  If you read up on this, it’s clearly a complex issue. Personally, I’m not at all convinced that Microsoft couldn’t have come up with a better solution, but we are where we are and the CLR simply uses a different memory model. The key phrase in the above article is this:

“Ultimately, as you all know, we decided to make a series of changes to the VB language to modernize it and make it more capable.  As part of this decision we decided to drop the VB lifetime compatibility requirements.”

Here we have it – Microsoft had decided to abandon VB6. It’s difficult to say which came first: the dropping of COM compatibility or the changes to VB. Probably, they were mixed. But the point is that is was largely a technical decision – not a marketing or commercial decision.

One thing's for sure, no-one asked the VB user base what THEY wanted. And the trains at this point are now well and truly rolling down the track.

It seems to me that the language changes got out of hand. Once you’ve decided to, say, drop the On Error syntax, then why not do a few more ‘tidy-ups’? Instead of some language changes which few would have objected to, we’ve ended up with a completely new language. But the major problem that people trying to migrate to the new VB language have faced (and still face) is that the gap between the old VB6 and the new VB .NET is simply too great to bridge. Microsoft provided a migration tool – sort of. In its initial version, this was infamous for its liberal scatterings of TODO comments, which essentially said it couldn’t do the job it was supposed to do. The Visual Studio 2005 version is better, but I wouldn’t like to migrate a major application using it – or even 700 or so smaller ones (as in one example).

Hindsight is a wonderful thing; they really ought to make a lot more of the stuff - the world would be a much better place. So, with that in mind, it seems to me that what Microsoft should have done was to have produced a VB6.5 and not wasted its time on a migration tool. Normally, when you upgrade a language, you ‘deprecate’ certain features. That is, you say that you’ll support them in this new version, but in the future they’ll be gone. That’s what VB6.5 should have done – provided an easier approach to the new .NET world.

I’ve seen arguments that this would have been too difficult to do: Microsoft would have had to bifurcate the .NET class libraries to support COM and the CLR. Microsoft has done that already for the Compact Framework, so it can’t be that difficult. Another argument is that VB6 was based on COM and COM doesn’t fit into the shiny new CLR world. Well, there’s a little thing called the COM interop, which does an excellent job (for the most part) of interfacing between the COM and CLR worlds. It’s perfectly possible to conceive of a VB Classic which interfaces to the CLR via the interop. And if you think that COM is dead or on the way out, take a look at the Visual Studio 2005 SDK – released just last month, remember. It’s COM; all COM; 100% pure COM. It seems that Visual Studio 2005 is written in C++ and COM.

In short, Microsoft could have chosen to do another iteration of VB6 as a bridge to the .NET world. To repeat, technically it was perfectly possible. Microsoft chose not to do that. It chose not to ask its users what they wanted. Instead, it’s ended up with “a language that never should have been invented and nobody wants.” Incidentally, I saw that comment attached to a Microsoft employee’s VB blog. It hits the nail right on the head. Truly sad, really.

So we’re now in the situation where if you are stuck on VB6 what do you do? Migration to VB .NET is likely to be painful and costly. Even if the migration tool is 100% effective (which it most certainly isn’t), you would still have to thoroughly TEST every single application – it’s a major language upgrade, after all. In the case I mentioned above there were seven hundred of them! The cost of converting and testing seven hundred applications is enormous. At the end of which ruinously expensive process, your business applications do exactly the same – no more or less – than they did before. It’s a curious thing that Microsoft has been so puzzled about the backlash it’s received from the business community. After all, from Microsoft’s point of view, VB .NET is technically better than VB6. But from the commercial viewpoint, it simply doesn’t do the business any better. Technically better most certainly does not equate to a better bottom line.

Further, just consider this: if your company has a major product based on VB6, do you really want to stop development of new product features while you get your twenty or so developers converting your million plus lines of code to VB .NET? Or do you want to hire another team for a year to do the conversion? And if word gets out to the competition that you are stuck on VB6, just how many copies of your product do you think you will sell? Interesting choices.

If you’re in that situation – not that uncommon, by the way – you can see why the suggestion (frequently made in print) that you aren’t living in the real world and should stop moaning and get on with moving to VB .NET is just, well, a tad annoying.

But if the commercial consequences aren’t too rosy for the poor VB6 customers, what are the commercial consequences for Microsoft itself? Start with some numbers. Say there are six million VB6 users out there (in the following calculation, you can add or subtract the odd million depending on your preferences, but the results are of the same order of magnitude). It seems that something like 2.5  million .NET licences have been sold. Let’s be generous and say that 1.5 million were for VB6 to VB .NET upgrades  - the rest being C#/C++. So that leaves around 4.5 million of the great unwashed VB6 users who haven’t seen the light and upgraded to VB .NET.

Now three years after the launch of VB .NET, to have 4.5 million users who haven’t upgraded is a bit of a problem. You aren’t going to get 100% upgrades, but you might have expected say 3 million of those to move. That’s 3 million at a (pretty conservative) estimate of $500 a go. Let’s see – that’s one-and-half BILLION dollars missing from Microsoft’s bottom line. That’s why it’s a disaster – for Microsoft.

You might try arguing that eventually these missing millions of VB6 users will migrate. Just imagine telling the CEO: “Don’t worry boss, the missing cash I promised will come in next year. Or the year after. Or maybe after five or six years”. Companies don’t work like that; try it and you’ll get fired. Especially if you’re a billion dollars south.

So here we are, three years after the launch of VB7 (aka VB .NET). Microsoft is missing over a billion dollars of upgrade revenue and it seems that VB6 users aren’t upgrading to VB .NET at all or are moving to C#. The VB6 user base is disintegrating. Instead of carefully looking after its user base, locking it in and ensuring that it can upgrade smoothly, Microsoft’s actions have resulted in the world’s most successful language blowing away in the wind. VB .NET books are not selling well. Publishers are just not in any great rush to commission VB .NET books.

Technically speaking, seven years after VB6 was released in October 1998, VB8 is now – at last - just equivalent to the old VB6 with the inclusion of the edit-and-continue feature. Putting this plainly, from a grunt programmer’s point of view – that’s someone who doesn’t do anything special, just knocks out useful applications and gets the job done - in seven years, (seven!) VB8 has not advanced very much over what was available in VB6. In some ways, it's worse: just try dealing with unstructured memory – it’s horrible.

By any measure, this is a disaster. How can a company possess a loyal user base of 6 million users and just throw it away? What level of insanity prevails at Microsoft? There have been many corporate disasters in the past – Coca-Cola’s new Coke and Intel’s Pentium bug being just two examples. These have found their way into MBA case studies at Harvard and other business schools. I’m pretty sure that Microsoft’s mishandling of its golden VB6 legacy will rank there among the finest. All because once the trains started moving, no-one could, or was able to, shout “STOP!”.

December 2005

Bytegeist Archives