Relaunching your website – the last excuse for a big bang release

I really love working in small batches as it ensures timely feedback and fast realization of customer value. Usually, we release two to three times a week – each release featuring only a handful of user stories. While I got used to working in this mode over the last couple of years, it’s really impressive if you look at how different working in big batches is.

Complete UI relaunch – a small batch killer

While I found it doable to break even big changes, like a complete migration to UTF8, into small batches (and therefore small releases), one final type of project is still eludes being dealt with in small batches: A complete UI relaunch.

Completely changing the look and feel of your application cannot usually be done step by step. It would seriously break the user experience and confuse your users. So you have to modify & release every screen at once. Hardly a small batch at all. Being forced to do such a big bang release leads to a couple of ill side-effects:

• Fear of features being left on the shelf: This is an interesting effect. Even if you’re used to releasing multiple times a week seeing a big relaunch approaching makes people feel itchy about a lot of really non-critical features or layout changes, which suddenly must be part of the relaunch. Somehow the fact that the next release after the relaunch is only a couple of days away disappears and people panic.
• Adding new features along with the new layout: Ok, new features might be a driver for the layout changes, so they have to come along with it. But as you are touching the whole UI anyways, there’s a big temptation to start changing a lot more things than just the layout. On the one hand, this can be very good if you do cleanups and refactorings, which improve the overall structure and code quality. On the other hand, every such change increases the risk of introducing non-UI related bugs. Of course, strong unit testing helps you here – but what if your test suite is far from being perfect…?
• Complete regression test necessary: While you can usually rely on automated tests and some clicking around for small releases, changing the complete UI suddenly requires a complete regression test. Full regression tests require code freeze periods to have a stable system under test. Such code freezes amplify the urge to add more features as it feels like a stand still – a downward spiral.

Fight for small batches

Seeing all the ill effects of big bang releases, it should be obvious that it pays to break big chunks of work down into smaller batches. While this might not be possible for such a visible change as a UI relaunch, at least factor out most of the new features and optional refactorings to keep the changes minimal. The temptation to bloat that one big release with a lot of bloat comes with drawbacks that far outweigh the hoped for benefits.