Recent reports that Microsoft’s latest release of Visual Studio (VS) has too many bugs again raise the issue of software quality. VS 2005 was a major software update long scheduled for release on 7 November.
Microsoft’s allies argue that it’s impossible to remove all bugs from such a substantial piece of software before releasing it to customers.
I agree with them to a point, but they are ignoring the problems that software makers create when they settle on a fixed delivery date, as Microsoft did when it decided the launch date for VS long before the product had finished beta testing.
Clearly Microsoft could only chose the release date of 7 November if it accepted the risk that the testers might find bugs that couldn’t be fixed before then.
Fixed delivery dates work to the benefit of commercial software vendors, though perhaps not their customers. Obviously, vendors need to manage their income.
Letting a product delivery date slip from one financial period to another could hurt a company’s share price. Vendors also need to book facilities such as conference centres and resources such as speakers and advertising campaigns to coincide with a launch.
Tying that lot together is tough enough when bugs are ignored, but is all but impossible if the delivery date is allowed to shift in the wake of bug reports.
All of this will come as no surprise to seasoned Microsoft customers.
The same combination of fixed delivery date and major software upgrade helped create the nightmare that was Windows 2000 and all its bugs.
Many software makers argue that firms in regulated markets and government departments should use commercial software that is covered by a support contract.
The logic appears to be that such software is the only stuff that can be assumed to be free of serious bugs. A parallel argument seems to be that open-source software cannot possibly be safe because you can’t pay the software developer to fix problems, and can’t sue anyone if problems turn to nightmares.
Tough luck on those who want to use Linux, or those who have a Windows NT4 system locked in a cupboard somewhere doing something useful. Such folk might have spent years removing or working round bugs relevant to their application. They might have a support contract with a third party in case their own people can’t fix things.
Clearly they would rather not change those systems unless there is a good business case for doing so.
Others will wait a year or so before putting the new Microsoft tools into production. Most people in IT learned the dangers of jumping to the latest upgrade a long time ago.






Do you agree?
Have your say on this article