The Tyranny of the Suite

Another common comment around refactoring has been: why do we have to wait for a whole other release to get refactoring? Why can’t you just do the features and then ship them when they’re ready?

The answer, for the moment, is that we are subject to the “tyranny of the suite.” Which is to say, we are so tightly bound to the rest of the suite of products that we ship with (C#, C++, J#, debugger, IDE, SQL Server, CLR, etc.) that it is extremely difficult for us to ship separately from the rest of them. In effect, it’s like we’re running some freaky twenty person version of a three-legged race. Because all our legs are tied together, nobody can move forward unless we all do, and coordinating everyone to step at the same time is a major undertaking.

This binding was absolutely necessary to ship the initial version of .NET because it was a v1.0 product and we needed every piece of the puzzle in place to make the system work. Now that we’ve moved beyond that, though, it does seem like it should be possible to move more towards a “ship early, ship often” strategy that allows individual pieces to innovate separate from the rest of the suite. Some things, like generics, would still require simultaneous work across the entire stack, but other things, like refactoring, could be done in smaller, incremental releases.

Now, whether this actually happens remains to be seen. A lot of the machinery that goes into release management is shared across the suite, and it’s not clear how possible it is to disentagle it all. Plus, the butterfly effect holds: small, out-of-band releases increase the test matrix and make it more likely that, say, a minor VB release could conflict with a minor ASP.NET release in ways that were very unfortunate.

Anyway, I think what can be said best is that we are always looking to improve our release strategies and get new features into the hands of our users as soon as possible. Time will just tell.

14 thoughts on “The Tyranny of the Suite

  1. Alex Kazovic

    < ![CDATA[Well at least you had the courage to reply to the criticism; although I'm not sure how happy it will make people. Has anybody taken some measurements to see where the blockages in the release cycle are? I’ve no doubt that people think they know where these are, but I can’t help thinking about improving performance i.e. you often think you know where a performance bottleneck is in an application. But when the performance is measured, it’s often somewhere different.
    ]]>

    Reply
  2. Karl

    Thanks for the follow up Paul…they really did answer the two specific questions being asked. It’s a shame that when you posted about refactoring everyone jumped up and down, but when you provided explanations everyone went hush…

    Reply
  3. russ

    < ![CDATA[You've just added more fodder to the "VB is a toy/sucks" camp. Programmers are just as political as any other group of professionals. If VB can’t maintain mindshare because C# always has the features first then I don’t see a future for VB at all. In the mind of most of the world we see that C# gets iterators, anonymous delegates, refactoring, AND swiped Edit & Continue. "Those guys must be really comitted to doing whatever it takes." — anonymous programmer Meanwhile VB plays catch up yet again (unsigned types, operator overloading, et al) AND manages to drop Refactoring on top of it all. "What a bunch of lazy-asses. They did the same thing with the last version. I’ll just use C#." — anonymous programmer #2
    Don’t make so many compromises doing what seems "appropriate" at the time that you end up with a product no one will use.]]>

    Reply
  4. Fan

    < ![CDATA[I think it's time to stop chasing C# in Visual Basic Orcas. I don't think good ideas are always created by C# team. Why C# features(like iterators, anonymous method) are so welcome? I think they are changes on the syntax to reduce coding work efficiently, not on the language runtime library. "My" is pretty good, but it has just such functions. If our task needs a function not included in the "My", it will not bring us any more convenience. We may have more changes on VB's syntax to bring new exciting and powerful features. VB should let us write less code to do more things, use simple (but not lack of function) structure to do complex things, and so on.
    A lot of dynamic languages have brilliant features on objects, strings, arrays, collections, design patterns and a lot of common tasks. Visual Basic can learn form them to became a more dynamic language. Visual Basic is supposed to the most productive language in the Visual Studio, isn’t it? I think it can be the best language too.]]>

    Reply
  5. paulvick

    Alex: Yeah, we’ve been doing a lot of analysis of our development processes over the years, although we’ve still got more to do. It’s definitely an ongoing experiment!

    Reply
  6. Alex Kazovic

    Paul, one thing I want to say; I hope we (or at least I) don’t come across as being to critical of you and the VB team’s work. We really do appreciate your efforts; it’s just that a lot of users of VB feel a sense of ownership of the product and want it to be the best it can be. So, if you can pass on this feeling of appreciation to the rest of the team.

    Reply
  7. Simon Geering

    < ![CDATA[Has anyone on the VB team not considered that it could be possible for refactoring support to be included at a higher level, as an add-in for VS ? MS has gone to so much effort to make a very powerful add-in support in the VS development tool and it would be nice to "kill two birds with one stone" so to speak. I would envision any such project would take a similar form to that of the Application Blocks ( i.e. unsupported MS produced best practice code) only in this case showing everyone how MS envision add-ins be developed and giving VB developers a powerful tool to boot.]]>

    Reply
    1. paulvick

      Simon: It’s definitely something that’s on our radar, it’s just beyond our current schedule. This is something that we’re thinking about beyond VB 2005!

      Reply
  8. Karl

    I know this is old news, for a not as old topic, but the ADO.Net team plans to ship ObjectSpaces as an addon to ADO.Net 2.0, hopefully that’s a sign of things to come…

    Reply
  9. Pingback: Panopticon Central

  10. Pingback: jim blizzard's blog

Leave a Reply