Avoiding Code Inventory with Staged Releases

elrina753

Have you ever found yourself in Sprint 4 or 5 without a single release under your belt? Is it because the new functionality involves a big database upgrade or depends upon coordinating three or four different departments? Not only does this kill motivation, but it’s extremely risky to push out this mountain of code and configuration changes to production all in one release.

Introducing ‘Sleeper’ Code

Whether it’s upgrading your application to support UTF-16 characters, or simply preparing a new header section for advertisements on your website, don’t get trapped into waiting for all the planets to align before releasing. Every sprint should achieve something, and a partial release is better than no release at all. The trick is to discover portions of the new functionality which have no other dependencies or, in the worst case, set runtime flags which hide or disable the feature until you’re ready to ‘wake it up’.

Objections: Is ‘Sleeper’ Code ‘Dead’?

When I first suggested this to my team, the response was unanimous and immediate – “No. This doesn’t make any sense and actually causes double work because we’d have to prepare the release and test it twice.” They even tried to change my suggested name to ‘dead’ code. Wow, I struck a nerve here. How to convince them this is the right thing to do?

First order of business was disabusing them of the notion that what the code they released would be ‘dead’. I argued that any code running in production is alive just by it’s mere presence in that environment. For instance, maybe the new code refers to some heretofore unused, conflicting libraries. During the release you’d probably have a much better chance at figuring out this one, simple problem. But what if this was step 27 in the release HOWTO? How long do you think it would take to troubleshoot then?

Heads begin nodding in agreement – so far, so good

The sense behind releasing ‘sleeper’ code is involving other people (i.e. departments) as early as possible and being able to plan your work in small, iterative chunks. In order to release to production, you might have to involve some database guys. Suddenly, the entire project has company wide visibility! And talking with someone about how to release a minor subset of functionality is something that takes an hour. Contrast that with releasing the “UTF-16 upgrade” project. You’d need to spend an entire sprint just to prepare this (not to mention the myriad of “Emergency Architecture” meetings your request would cause to ripple through all involved offices).

As for having to test twice, ever heard of automated testing?