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. 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…

  2. russ

    Don’t make so many compromises doing what seems "appropriate" at the time that you end up with a product no one will use.]]>

  3. Fan

    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.]]>

  4. 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!

  5. 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.

    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!

  6. The Slashdot Collective It would appear you’re attempting to patent the idea of testing pointers for inequality. What the FUCK is wrong with you, you motherfucking asshole?!!]]>

  7. 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…

  8. Pingback: Panopticon Central

  9. Pingback: jim blizzard's blog

Leave a Reply

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