The cost of frequent bits updates

Sharing Whidbey interim releases more frequently  (Mark Cliggett, via JayBaz, via Scoble) with our developer community is a great step for MS, I think.  I love to see the Whidbey team being more open and engaged with the community


On the other hand, there are downsides to having frequent releases:

1)      Quality of each build is less determinate, as Mark points out in his blog entry.  While each new build will have features that didn’t work before, it might also break things that previously worked well.  If you have 50 developers checking in 3 fixes a day, even a low low regression rate of 1% leads to 7 or 8 new issues each week

2)      Less community consistency – the odds that you have the same build as the other folks on the newsgroup, or the guy posting sample code on his blog, start to go down.  This has the potential to really harm the community I think, if we’re not able to help one another out with issues or post samples that work for everyone.

3)      Cost of wipe-and-reinstall.  Interim builds likely won’t support any sort of upgrade, or patching (as has already been requested in some blog comments).  So you’ll have to download the whole thing, uninstall the old build (assuming there aren’t any bugs in the uninstaller that instead require you to reformat and start from scratch), install the new build, and then manually fix up any code that no longer works.


I’ll be interested to read the general reaction to the more frequent releases.


There has been some chatter about whether releases should be made available to the general public, vs. only as a download for MSDN subscribers.  I don’t have any insight on what path the Whidbey team might chose, but for me, the issue is not one of elitism, as some commenters have suggested.  I think it’s more about managing expectations.


Putting up a new build for a limited audience of committed MS developers (MSDN) sends the message that this build is not ready for prime time, and it’s stability is low enough that the casual/hobby  programmer won’t get much benefit out of it.  Putting up a build on or where the whole world can download sends a stronger signal that this is a build many people could benefit from.  At least, that’s how I’ve heard it discussed internally.


Of course any build on MSDN will get broadly leaked anyhow, and pirated onto CDs in Singapore or what have you.  That’s why the point isn’t about access, it does seem like anybody who wants the bits will be able to get them regardless.

Comments (2)

  1. Wallym says:

    I would prefer to have access to updated bits than to not have access to those bits. Keeping upto date becomes the responsibility of the developer and is something I am willing to do.

    As for updates and reinstalls, that is what VMWare and VPC are for. 🙂


  2. Ferris Beuller says:

    Yes because having non subscribers evaluate a product because they too can deliver value to a platform is bad and the moon will deorbit and all planets start to bounce into each other.

Skip to main content