Does code quality define Microsoft's success?
April 27th, 2007 by Rich Sharpe. Posted in Software QualityCurrently the IT media is fawning over Wednesday’s public beta release of Microsoft’s Windows Server Longhorn Beta 3. With most customers planning to wait at least a year before upgrading to Longhorn, a lot of focus will be on the organizations willing to jump into the game of “Russian Roulette” when opting to upgrade. For those that do, there will be some additional overheads: hardware (I’m assuming they are going to run in parallel with current systems for a while), software (obviously) and training. But the main focus will be the comments on installing, reinstalling, configuring and managing this system. Oh, did I mention reinstalling…?
Obviously many, many companies are reliant on Microsoft’s products (us included) to run their business, and it has become the norm to expect quick bug patches and late releases of Service Packs as experience has demonstrated. There seems to be an almost audible ‘groan’ in the industry when something goes bad with a Microsoft product, whether it is a slip in release date or security issue, followed by an ‘understanding’ sense of “Well, it’s Microsoft, they’ll get it fixed soon”.
Joe Wilcox’s article in eWeek, Microsoft’s Big Bang is When? is an unsurprising stream of unreconciled comments from various product managers, vice presidents and the marketing department. Another common part of Microsoft’s reputation in the past.
In my opinion, these issues are largely a reflection of the quality of the various Microsoft products’ code bases. The rewrite of the Vista code back in 2004 must have sent shivers down the spine of management at the time. However, this decision was made on the basis that the quality of that code would have not been anywhere near what has been released this week, so the fact that Microsoft actually made that tough decision must be applauded. It is rare to see such things reported in the media, and moves the industry toward raising the ‘quality’ issue and demonstrating that quality does matter to us. It reminds me of the ‘prototyping’ practice – how many teams have just continued to build an application on top of prototype code rather than scrapping the prototype and rewriting a better quality application?
The recent flurry of security holes found and patches delivered to key Microsoft products also serves to taint their reputation but being the organizational giant they are, with millions of happy users around the world, the image they project with a great marketing campaign and the reputation with home users, significantly outweighs their quality problems.
My conclusion? You could not honestly say that code quality plays a big role in Microsoft’s success. You’d have to say that they are better at marketing than at creating high quality applications. But, it’s truly encouraging to see them making bold decisions to improve the quality of their output, which sets a great example for the rest of us, who may not have the, uh, inertia of a company like Microsoft.
Leave a reply
You must be logged in to post a comment.