Last Monday, the day before Blaster (or MSBlast or LoveSAN, as it’s also known) began circulating, Microsoft New Zealand took the unusual step of reminding us of the flaw in Windows’ RPC (remote procedure call) code first reported on July 16. It issued a press release urging users of Windows NT 4.0, NT 4.0 Terminal Services Edition, Windows 2000, Windows XP and Windows Server 2003 to apply patch MS03-026. About 12 hours later came the first accounts of a worm exploiting the hole.
Microsoft NZ says the timing of its warning and the arrival of the worm were coincidental. It also says it was the only subsidiary of the company anywhere that took the unusual step of issuing the alert. It did so not because few people had downloaded the patch -- it says it has no way of counting on a local basis -- but because the hole had the potential for disruption on the scale of the Slammer and Code Red viruses.
It’s all terrifically embarrassing for the company, 20 months after its much ballyhooed "trustworthy computing" initiative. Trustworthy computing would shift the emphasis from adding new features to products to enhancing their security. Windows Server 2003 was the first product out of the lab since the initiative was launched.
How does a hole as big as this get past the company’s software testers? Never having written a line of code in my life (I reluctantly accept that the eight-line Fortran routine written in the seventh form for finding an average doesn’t count), I’m forced to look for a journalism analogy. Given that this flaw goes back to NT 4, it’s like copying and pasting from an old news story into a new one the most damaging defamation you can think of -- "Bill Gates is a baby killer", say. And then no one noticing -- reporter, sub-editor, editor, proof-reader, subscribers -- for several years. In our line of business, that would qualify as complacency.
When the RPC flaw was found, the head of Microsoft’s security research centre, Kevin Kean, insisted trustworthy computing was working. The proof was the relatively low number of flaws uncovered in Windows Server 2003 compared with Windows 2000 at the same stage -- four versus 14.
Software testers will tell you that it’s not the number of bugs that count in a finished piece of code, but their severity. By that measure, Microsoft’s record can hardly be said to have improved. Testers also say the key to doing it well is management and planning from beginning to end of the development life cycle.
Financial management is what Microsoft excels at. It needs to apply some of those same skills to its software development management. It should start by offering refunds when its products go wrong, and be prepared to slow its product release schedule -- so important for keeping revenue rolling in -- until the software is truly ready.
Show-stopping bugs are a failure of management rather than poor programming.