Hotfixes are, well, just that…

In response to my entry on VB hotfixes being made more available, Paul L brought up a point that’s worth addressing:

While this is great (and long overdue), the truth of the matter is that most companies do not have the time and resources to download these hotfixes, test them, and then propogate them to other teams. Indeed, after installing *all* of the hotfixes that you list we still had envrionment issues that remain unresolved. Sure, we can contact PSS every time we run into something, but aren’t we supposed to be spending our times working with tools that are just supposed to work out of the box…

I should have emphasized that the hotfixes are, well, hotfixes. We also call them “QFE”s, which stands for “Quick Fix Engineering,” which should give you a further appreciation of their nature. QFEs are produced in response to urgent customer product support requests and although we take as much care as possible with them, they are intended to solve the specific problem and are not put through the extremely rigorous tests that a full release or service pack gets. Thus, installing a hotfix is really only for people who need their particular problem solved. Everyone else should wait for VS 2005 SP1, which is already in beta and will contain lots of other fixes and will be much more rigorously tested. Seriously – if you can wait for SP1, you should. It’ll be much better.

Paul continues with:

Instead, we made a more strategic choice to simply convert all of our VB applications to C# and we haven’t looked back. In each case, the application conversion process took a day or two (thanks to the conversion features of SharpDevelop) and I can certainly say that our development experience has been on orders of magnitude more stable and reliable with the IDE experience than it was with VB.

I feel extremely regretful that the C# experience has been so much more stable for Paul than the VB experience was. I’ve been doing a lot of development work in a mixed C# and VB solution recently and haven’t noticed any difference between the two in terms of stability, but as is obvious from the hotfix and SP situation, there are some problems. There shouldn’t be any difference between the two IDEs, but I think that part of the problems, such as there is, stem from the greater ambitions of the VB IDE. I find it very annoying switching between C# and VB because I’m always missing my background compilation and much more accurate (in my experience) Intellisense when I flip over to C#. This comes directly from the greater integration between the compiler and the IDE, which also means that there’s more opportunity for problems and for us to screw things up.

The interesting thing to see is what happens in Orcas. With a much greater reliance on type information that type inference demands (both for local variable type inference and lambda expression inference), C# is going to need to forge much closer links between their compiler and their IDE, similar to what VB has done. What effect that will have is going to be interesting to see.

7 thoughts on “Hotfixes are, well, just that…

  1. Sergio

    Your last paragraph can be (maliciously) interpreted as "I hope C# gets as slow as VB in VS Orcas…. That should stop all the whining." But I know that was not your intent 😉

    Reply
  2. Mike Gale

    This experience surprises me.

    I’ve done work with some parts in C# and others in VB and haven’t noticed these differences. (In some cases I’ve taken C# bits and made them into VB, maybe using SharpDevelop.)

    Some further detail would be useful:

    1) Profile of what’s happening. Are there differences between developers.

    2) Description of working environment. How machines are connected, organisation structure, political dimensions…

    3) Analysis of what is causing the issues.

    I know we aren’t going to get any of this, but without it, I draw no conclusions!!

    Reply
  3. RichB

    It’s not only the IDE.

    In RTM, the VB IDE was much slower that the C# IDE. The VB language was much buggier that the C# language.

    The same is true with Whidbey. The IDE and language are both buggier.

    You can come up with detailed metrics on these (I did on the first back in 2002) and the second you just need to look at the top 10 hotfixes. See which ones are C# related? exactly.

    There has always been a "see what happens with the next version". I remember the same sentiments back in RTM & Everett. The plain fact is that over 3 major releases, C# has been the more solid platform to work on. The VB team need to prove themselves solid for me to move back to where I spent 5 years coding.

    Reply
  4. Paul L

    Paul,

    Thanks for the follow up post. I’m glad that my comment was noticed and I can certainly tell that you are sensitive to the challenges we’ve had with the VB IDE.

    I would generally agree that the cause for the problems I’ve experienced may well be due to the ‘ambitions’ of the VB IDE and that feature point is certainly compelling, and when it works, it works great! (Sure beats building your C# project to get rid of the squigglys as you develop… but at least with TDD and TestDriven.NET that pain is lessened.)

    Forward looking, I agree that the C# experience will absolutely have to improve to be able to match the demands of the upcoming languages changes, but tomorrow is tomorrow, and those of us out in the ‘field’ must look for solutions that work for us today.

    Mike –

    1) Profile of What’s happening – Writing code in the VB editor. The majority of our problems, by far, occur here.

    2) Working environment – strange question, but network on a lan with internet connectivity, agile development shop

    3) Analysis – heck, just look for my IP address when searching the OCA reports for my VS crashes 🙂

    RichB – I certainly agree with your language comments. We’ve encountered quite a few strange language gotchas that have surprised us, but were easily worked around.

    Finally, lest I be mistakingly confused for a C# zealot (grin), let it be know that I’ve printed out Paul’s language specifications and have actually read the majority of it end-to-end. 🙂

    Reply
  5. Paul L

    Now, also, speaking of the VS 2005 service pack, when will it be released? We were just about at the point where we were going to install the beta service pack before the DevDiv released all the VB hotfixes (whose download links mysteriously have disappeared since, btw).

    When will the VS 2005 service pack 1 ship?

    Will we see it before Orcas ships? No seriously, we didn’t see the 2003 service pack or ANY hotfixes released publically until 2005 hit the streets. (Paul – what’s the story behind that, care to share?)

    Making these hotfixes and service packs available to the general public goes along way toward projecting the "right" image by Microsoft to the dev community, and I eagerly look forward to the forthcoming releases.

    Reply
  6. paulvick

    Sergio: I can understand how one could read it that way, but I should clarify that it’s not true. The two teams sit next to one another, and we’ve done a bunch of consultation with them to talk about the issues we’ve run into and things they’re likely to encounter, and we’ll continue offering any help we can. (Their goals and architecture is a bit different than ours, still.) Our goal is for *both* teams to get better.

    Paul: My belief is that the SP1 beta contains all of the existing hotfixes, so the beta is the way to go if you want to take it on. As far as scheduling goes, I don’t have much to offer–I can’t seem to find the public statements that I know have been made about timing for SP1, and I’m not actually that knowledgeable about the planned timing. (Ditto for the story behind 2003 SP1.) Not my department, as Tom Lehrer says about Werner Von Braun. 🙂

    Reply

Leave a Reply

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