After my prior post on VS 2005 bugs, I found my name, splattered all over the blogosphere, culminating in a mention from Mini-Microsoft regarding VS 2005 stability. My post along with those of Frans Brouma and Roy Oosherove initiated a viral phenomenon on the Internet.
Despite the few hiccups, I am enjoying VS 2005 and have been able to work with it productively. VS 2005 is stable and performant, and it’s better to have it arrive now rather than later. The runtime is solid, and various products across Microsoft and outside also depend on it being delivered on a timely basis.
Chris Pratley explains why it’s not practical to remove every known bug; otherwise, the product will never ship. Most bugs have negligible customer impact, yet the act of fixing them often introduces additional bugs (“regressions”) into the product that are likely to be of even greater impact; bugs found close to the release date go through a triage process. Shipping the product later may not considerably improve the product, because of diminishing returns.
There’s also the tradeoff of features against quality. VS.NET (2002) shipped with a number of bugs such as blowing up after encountering a stack overflow exception; VS 2003 introduced few new features, so it was more like a service pack; hence, the quality of VS 2003 is apparently greater than that of VS 2005.
My Internal Compiler Errors initially appeared to be a showstopper, but were due to some inconsistent state in the IDE that necessitated a restart of the application. I later realized that my project was converted to VS2005 after Beta1 around July 1, 2004, which was over a year ago. Any problems that I am seeing may have been done due to changes in VS 2005 since that point, and so the errors may not be a true reflection of VS 2005 stability. This could well be true in the case of MVPs and other influentials, who having been continuously developing with beta products.