24 January 2011

Google Chrome and the Release Cycle

Google Chrome Logophoto © 2008 Randy Z | more info (via: Wylio)
Back when Google Chrome debuted, I thought it an interesting concept, but not something I would ever use. I was a Firefox diehard. I was one of the few who could (or at least would) admit to never having willingly used IE. Even during the dark days of IE dominance, when Netscape 4.76 was the only competition in the land, I still refused to move over to the spinning 'E'.

So, one year ago, when Chrome gained extensions on the Mac, I decided I would spend one month testing to see if it was usable. That one month has very quickly turned into one year. Despite the great leap forward Firefox 4 is showing to be during its beta period, I still don't see myself returning to it anytime soon. The release management differences between the two competing browsers is, in my opinion, a lens into my reasons for switching.

Back in July of last year, when Google announced that it would speed up the Chrome release cycle to a new version every 6 months, I was at first incredulous and secondly, I thought it preposterous. Really? What kind of major coding could you get done in 6 weeks that would necessitate an increase in a major version number? It wasn't until I came across this set of slides that I came to understand the answers to my questions:
Chrome Release Cycle 12-16-2010

Reading through the problem, I can see why they moved to the cycle they did. I can't say I blame them as the end of a release cycle is always fast and furious. We tell ourselves, never again will we do this, yet a few months later, we find ourselves doing the exact same thing.

The decision to focus on features and not on release numbers or date driven development is impressive, but sadly probably not an option for most of us who are not Google. I don't think that most non-IT management, and even a lot of IT management, really gets what its like to work a well-run development cycle. It is hard, but giving them a solid date and a version number gives many of them a false sense of understanding because numbers and dates are something they 'get'. If we tell them we have a plan for delivering v17.9 on January 31, then that's great, right? Well, maybe.

But what about that line that discusses disabling features with a single, small patch? This I like. I always wondered how features that take months to develop could be held safely during all that time. If a developer kept all that code on their local drive, which then had a failure the day prior to completion, all that work would be wiped out. Sure, private branches in version control systems could be used, but they clutter up your system with a bunch of dead branches once you're not using them any more.

Another advantage I see is that by doing this, you force the developers to keep dependencies between code modules at a minimum. If any feature can conceivably be disabled with a single patch, you ensure a better, more maintainable architecture on your application.

The last thing that stood out to me was really a question. If you move to 6 week upgrade cycles, why do you really need a version number at all? Sure, its easier for us as humans to remember 'v17.9' than it is a build number output by some compiler, but really, does a version number matter at this point?

From a purely logical standpoint, I don't think it does. Google could still put out a press release every couple of months touting a new release of Chrome that includes feature XXXX or decreases page load time by 17%. They don't need to specify a version number, just that 'you'll be getting it soon'. For the 'About' page in the browser, you just need to know if you're 'up to date with the latest browser version' or if you need to do an update.

Sure, you can say that having v17.9 sound more advanced than having v2.7, but versioning has always been at best an art and at worst, a marketing farce. I am just beginning to wonder if we shouldn't start working towards the 'post release number' era. I don't see that they provide much worth in the modern world.

4 comments:

  1. I agree that referencing the release number is antiquated and that other approaches can be viable siting Google's Release Management for Chrome. Can this new era of understanding release management be adapted into other developments?

    For most end-users having to refer to a release subjectively as 'up to date' or 'out of date' is abstract and pushes against the old paradigm, a "marketing farce" as you mentioned. Can this be easily accepted or will it wire-in confusion on behalf of the end-user?

    Will developing a release that concentrates on flow rather than scope become a smooth transition for other developments as the discipline improves?

    ReplyDelete
  2. Anonymous1:10 am

    "For the 'About' page in the browser, you just need to know if you're 'up to date with the latest browser version' or if you need to do an update."

    The issue being how do you reliably know that you are up-to-date or not without a version number to double check? I have seen multiple apps report that no new version is available when a new version is indeed present at the apps' website. Bugs can occur in the update code just as easily as anywhere else.

    ReplyDelete
  3. A release number is useful when managing support issues. Certain versions have known issues that are resolved in later versions. That's the best utility you get out of version numbers.

    Ted - go for it. Shoot for 6 week release cycles, and when you get there bring it down to fortnightly. Eventually you'll see the potential of daily releases.

    Awesomeness comes in increments.

    ReplyDelete
  4. This is where sensitivity analysis can come to your rescue. What a sensitivity analysis does is it allows you to play "what-if" games with your assumptions. You can hold the other assumptions steady while you vary one of your assumptions. What would happen if the company didn't get that new contract? What would happen if one of your software vendors suddenly doubled the price that they charge your team each year? What would happen if half of your kmo ITM suddenly decided to leave and had to be replaced?

    ReplyDelete

Search This Blog