Is VB 2005 buggy?

In the comments to my notice that we shipped, karl asks:

I haven’t played with VB.Net 2005, but are all of the bugs also causing problems? Most seem CLR related, but with a hint of IDE link, and I know C# and VB.Net don’t share all the IDE code.

The list of reported issues has put a halt, possibly permenantly, on my push to upgrade the entire team to 2005.

I’m guessing Karl is talking about a lot of the blog entries that came out around the release of VS 2005 to MSDN subscribers, some of which are summarized by MiniMSFT.

So, is VB 2005 a buggy piece of crap? In a word, no. Although I have not been intimately involved with bug triage for quite some time, I do know that we’ve spent a very long time working very hard to ensure that VB 2005 (and VS 2005) is a solid, quality release. My own personal experience with it is that it’s very stable and so far I don’t see a groundswell of complaints that would indicate serious problems.

When, then, to make of the brouhaha? Well, first we should be clear: VS 2005 shipped with bugs. This happened for two reasons. One, as has been discussed elsewhere, the only way to “converge” on a release is to steadily raise the bar for the severity of bugs that you’re going to accept fixes for in the product. This is because every bug fix, no matter how benign, has the possibility to uncover or cause more bugs. Ergo, the only way to reach a steady state is to stop fixing most bugs. Some bugs, I should be clear, are always going to be fixed if found before shipping — if we product incorrect code, for example. But others can be postponed. And this is how it’s worked for pretty much every product you’ve ever bought from Microsoft (or any other vendor, for that matter, I would guess).

The other reason VB 2005 shipped with bugs is that I know that there are bugs we didn’t find. Again, Whidbey was a pretty long release cycle, so we had plenty of opportunities to flush out problems. But no matter how hard we look, there are always bugs that slip through. We could spend years in beta and still would find serious problems after we ship. It’s a fact of life given the myraid of different ways that our products can be used.

OK, so what about the reports of bugs bouncing around the blogsphere? Like I said, it’s inevitable we shipped with bugs so I’m not surprised that, given the high level of sophistication of the most prolific bloggers, a few things are going to show up right away. Murphy’s Law in action. However, as I also said, I’m not seeing the volume that would indicate significant problems. Instead, it’s a handful of reports that have then been bouncing madly around the echo chamber of the web. This doesn’t mean that the bugs that have been verified aren’t real or aren’t serious — any bug that impacts a customer is a serious problem and one that will need to be addressed — just that the preponderance of the evidence so far is that we’ve got a solid release. Time, of course, will tell. I encourage anyone who’s worried about the stability of the release to: a) give it a bit of time and see what the consensus is after people have had a few months to live with the release, and b) try it out yourself and see what you think, either by using the trial version or the Express version (see here for links to those).

All this is deja vu for me, I might add. The very first product I shipped at Microsoft was Access 1.0. It was a great product and a solid piece of engineering. However, we had a slight mishap — during the launch event at Comdex, Bill Gates was up on stage with someone (forget who) doing a demo of the great features of Access 1.0. Everything was going great and then suddenly WHAM! Access crashed. (Thankfully, I was in the second wave of team members to go down to Comdex, so I only heard about it. Half the team had to sit in the audience and just watch the whole thing unfold.) This wasn’t great, but in theory it wasn’t the end of the world — after all, it was just one crash. However, Phillipe Kahn, whose product Paradox for Windows we had just beaten to market by (I think) a good six months, saw an opening and started going on about how people shouldn’t buy Access because it was “too buggy.” Was this true? No. Did it matter? Not really. The perception stuck and was part of the reason that we shipped a 1.1 version, so people would think that we fixed all those nasty bugs that weren’t really there. (Of course, in the long run, Access did just fine.)

I doubt that’s going to happen here, thankfully…

55 thoughts on “Is VB 2005 buggy?

  1. megaboff

    very buggy and takes up lots of memory.

    Also: Did not work properley with my velleman interface board, had to compile it to get anywhere!!!!!

    However VB6 is a different story, stable and much more sensible

    Reply
  2. Jamie

    VB6 was stable. It might not have had all the bells and whistles of VB 2005, but it did what you asked it to do and quickly. The IDE was clean and easy to use, and even if you had to load 5000 records in the IDE, it did it fast. This is not the case in vb 2005.

    Not only that but vb 2005 is not a new version of vb6. It is nearly impossible to convert large applications over to vb2005 and there are alot of large programs built on vb6. The vb 2005 information relys heavily on the SQL express server, and very little information is given about connecting to an access backend oledb provider.

    Which is interesting since Access is still around isn’t it?

    Reply
  3. Adelio Stevanato

    We only moved to VS2005 (VB) six months ago!. We are a business using VB for internal systems and until service pack one was releases the IDE was useless (try using it with multiple monitors).

    VS2003 was a Steep learning curve but after a while we grew to like it. There was no real reason for us to move to VS2005 (we only wrote thick client stuff) NO Web!.

    VS2005 has been a big dissapointment. Every member of the team has the same problems with our main application (VB, 16 projects, thousands on files) when we close the IDE it usually crashes, Not always but mostly.

    Also the IDE will crash randomly when editing code. Looks like it might be an issue with the background re-compile.

    The other issue, as other people have said is trying to view the designer. This was SLOW… in VS2003, in VS2005 it is practically unusable. and it is not unknown for the ide to NOT display the form in the designer but display an error message which then requires a full re-compile of the project to fix.

    Not sure if the slowness of the IDE is not related to the fact that all forms are inherited from customer base forms and we have extended the functionality of the textbox, combo (and other) controls.

    The Microsoft Comunity forums just have never worked properly, they just seem to hang if you want to view a specific item.

    I would rather wait ANOTHER year or TWO for Microsoft to build a robust and reliable product than ship a half finished, slow and buggy one.

    What is the point of new features if the product itself is unreliable.

    Reply
  4. Steve Brecht

    I just put in VS2005 a few weeks ago as I needed it for a CE/Mobile project. On a completely clean and patched Thinkpad it took me three installs before I actually got it working enough to develop with. The ‘fix’ for one of the issues was to uninstall the compact framework that comes with VS2005 and install a different one. Still couldn’t launch a new VB/Mobile project without a "Failed to start compiler" message. In the end I found I am unable to have .NET 3 installed in any fashion for it to function. Even now if I put in .NET 3, even through Windows Update, VS2005 stops working.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *