Visual Studio 2005 and the quality factor |
 |
By Mike Gunderloy
21 Nov 2005 | SearchVB.com |
|
|
It wasn't long after Visual Studio 2005 launched - and by "not long" I mean "within hours of the RTM bits appearing on MSDN" - before people started publicly complaining that this release was rushed out the door and not the sort of quality software that Microsoft should be shipping. High-profile developers like Frans Bouma quickly ran into issues with the RTM build. Perennial critic Mini-Microsoft based an entire blog rant on the early reports, suggesting that the product was rushed to market so that the company would have something to crow about at the shareholder meeting, and the heck with quality.
I haven't run into any data-loss bugs myself, though I have had a fresh install of the released VS2005 mysteriously crash on a clean machine, and I've got this wacky flickering repaint problem on C# Windows forms on another box. Clearly, the product isn't perfect. But I've got a different view on this lack of perfection. I don't believe that we've particularly got a product issue here, but a perception one. In some ways, that's even worse for Microsoft, because it's going to be much harder to fix. Let me explain.
Every single version of Windows, Office, and Visual Studio (and any other product of similar size, for that matter) has shipped with bugs of the magnitude that people are reporting in VS2005. So why are we suddenly so hyper-aware of the VS2005 bugs? The difference is not in product quality, but in two other areas. First, the developers at Microsoft were incredibly open about the development process in this product cycle. For the first time multitudes of people got to see the realities of bugs being triaged to meet a ship schedule. I've seen some online expressions of shock that a bug-fix could be postponed to the next release of the product, but in fact this has always happened. If you don't stop fixing bugs and ship software at some point, you don't stay in the software business for long.
Second, the blogosphere makes it incredibly easy to find and publicize the people who are finding the bugs; previously you had to be in product support to hear those conversations. If you're Frans Bouma or Roy Osherove and you hit a bug, your blog post on the subject can ricochet around the Web and get picked up by news sites in a matter of hours. It's incredibly hard for any company's publicity machine, even one as finely-tuned as Microsoft's, to do anything about this phenomenon. (And when someone later finds a workaround or a mistake in their own code, well, those follow-up posts just don't get the same wide dissemination).
All of this is cold comfort if you happen to be one of the ones bumping into the bugs, but I think it's reality. Most of us are not working in a realm where perfectly-verified computer programs exist. It's just not cost-effective to eradicate the bugs in something like a development tool meant for the mass market. The interesting question is what Microsoft can do now to counteract a growing perception that they shipped junk. They've already made one move by announcing a quick service pack for some time in the first half of 2006. I'd expect a continued selection of case studies of companies that save time and money with VS2005 as well. Ultimately, though, there's no alternative to using the tool on your own projects, discovering the areas where bugs remain lurking to bite you, and finding the workarounds - just as we've been doing with our development tools all along.
Take part in our Quick News Poll: Do you think VS 2005 is ready?
Mike Gunderloy is the Senior Technology Partner for Adaptive Strategy>/a>, a Washington State consulting firm. You can read more of Mike's work at his Larkware Web site, or contact him at MikeG1@larkfarm.com.
|
|
|
|
