Keeping your options open

Recently, on a project, I’ve been learning about Lean, Real Options and Kanban.  On the project we used these principles to guide how we architected our release process so we could be ready to release at any time (mostly) without branching.  We did it mainly by being able to use config to turn features on and off, and aiming for backwards compatibliy.   That way if you deploy a new version, but don’t turn on the new features, it works exactly like the old version.  This means multiple features can be developed in parallel, and a release can be made when any one of them is ready.

Chris Matts my old project manager started a thread on the kanbandev mailing list asking if other people used similar techniques:

One of the most powerful techniques I have used over the last three years is latent code patterns. The project I just left made every feature configurable. This meant that we never had the situation where a fix / feature had to wait for another feature in testing. We focused on fast and effective regression testing. Despite frequent diva releases we only ever had a single branch and had no code merging issues as a result.
Is anyone else using latent code patterns? I would like to hear how others do it as the best lnnovation comes from practitioners with a problem.
The other issue that lcp raise is the wip limit around testing. Thoughts?

I’m not scared of SCM branches and merging, I can merge with the best of them.  Inspired by Chris’s demand to defer commitments, I made a conscious decision to avoid all branching unless absolutely necessary.  At the beginning it was an experiment, encouraged by the cost of branching.  The cost of merging, resolving conflicts, tracking which bugs are fixed where etc all add up.  That time and energy can be better spent finding a solution whereby we can make decisions as late as possible.  We wanted to able able to sense ambiguity in the requirements and code it up both ways, make it easy to change our minds.  Reduce the cost of change.

From the responses it seems some of the ideas we’ve been using are in use by others.  Some mentioned using dependency injection, but it’s not clear that others were affecting dependency injection at runtime like we are.  Others mentioned the command pattern, and it did indeed sound similar to our approach.

The thread was also summaried in the InfoQ post Enabling the Last Responsible Moment in Deployment which I think is a fairly good summary.

Next I will cover the techniques we use in more detail.