VS 2005 - Why do you want to make trouble?

(There goes my conscience again. This started as a comment that got longer and longer until it reached post length.)

This is a follow-up to last night's VS 2005 + Bugs = unhappy bloggers post. Some additional posts out there:

• A new Channel9 thread is here: Did VS2005 Ship Too Early?
• Channel9 has a Coffeehouse thread: Bugs in Visual Studio 2005 RTM
• Christian Graus notes IDE crashing
• Thomas Tomiczek has an entry called Growing Pains :-)
• Help.net has a post Alarming issues with Visual Studio 2005

Looking through the comments...

Mini, you might want to try using the products your own company produces before you declare it an utter failure and the buggiest thing ever.

:

It seems as if this blog has recently changed its tone from something that offered constructive criticism and useful insights to the kind of drivel you'd expect to see on slashdot.

Ye-Ouch! I did struggle with the negative nature of this post. I struggled with the fact that I personally felt that VS 2005 environment was a slow moving, buggy trainwreck yet I didn't reach for the emergency brake line and give it a good pull and call BS. I had hopes that it would stabilize well at the beginning of the escrow process.

What makes me especially angry is that our customers were pleading for stability and speed and we steamrolled over them with this release. I appreciate that it's a large environment and most of it will be just fine for most people and folks who really want to get work done will figure out where the last mine blew up and not do that again. It's their own sort of version of Twister to get their work done.

In my opinion, what VS needs to do is say, in a manner that won't dampen the launch party: Hey, this was a super-big innovative release but it looks like some bugs unfortunately shipped. Okay, we're really going to ship a VS 2005 service pack. Here's the Microsoft forum we'd appreciate you providing feedback to. Here's a link that you can keep track of what's going into the service pack. Furthermore, the service pack will ship on fill in a date no longer than six months out.

This is because the users are complaining that they've never, ever seen a patch or a service pack for VS and they expect they are going to be told to wait until the Orcas release. If that's our plan, we should say so.

Another comment: This is a prime example of what's wrong with pulling six blog comments out of the blogosphere and holding them up as proof of a poor decision. I'm willing to bet, though am too tired to actually do so, that for every negative comment you'd be able to find 15 or 20 positive comments.

I bet you're right, too. If folks want to balance this or the other post out with links to people using the VS 2005 RTM bits and being pleased silly, please do. In the meantime, unhappy bloggers aren't going to go away. I appreciate that some Microsofties are spending time and effort to go out and put down comments in those blog entries complaining about issues. Hopefully that helps. But you have to realize this: that every really bad bug you say Won't Fix to is going to end up on someone's blog post eventually (especially considering the technical nature of the VS 2005 customers). It's not just a one-on-one call to PSS you have to worry about anymore. It's pissed off users venting to the world that the software they paid good money for is hanging, crashing, or corrupting their data.

Another comment: For several products, employees are required to use the product as our customers would use it before it ships.

In a lot of groups, the VS IDE is not used by developers.

Internally, it would be good to figure someway to dogfood VS 2005 at a greater rate. Most developers, who find the choice, draw the line at Rascal. But if we were to dogfood VS 2005, I'd want assurances of support from that team and a promise that there were going to give us stable drops. I don't think dogfooding VS 2005 was totally possible this time because of the rapidly mutating environment rushing up to ship.

So. Too negative? Look, I think given time that the VS team would have fixed a lot of the bugs (and they do seem to be pretty much in the IDE, I haven't run into a compiler bug in a long time let alone run into a post about the compiler). But they weren't given time because what they were shipping along with had to get out the door. This wasn't news to the division. If the date can't move, major features get cut so that the more important features can be stabilized with the available resources. It's not rocket science. It's computer science and software engineering. And we do it enough every day such that big nasty bugs shouldn't be shipping in one of the jewels of the Microsoft franchise.

A cautious example to Windows Vista and Office 12. You have to ship in 2006. Are you ontrack for a high quality release? Would it be better to cut major features now and save them for the next release so that you can have a super-high-quality release now?