Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Enabling the Last Responsible Moment in Deployment

Enabling the Last Responsible Moment in Deployment

This item in japanese

Chris Matts started a conversation with the following question:

One of the most powerful techniques I have used over the last three years is latent code patterns(lcp). 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 innovation comes from practitioners with a problem.

The other issue that lcp raise is the wip (work in progress) limit around testing. Thoughts?

Basically, what Chris was reporting is his team's ability to be able to turn on and turn off features at will. Therefore, even if a feature is in-progress, it does not block the team's ability to release at-will because the feature can be turned off.  Chris later stated the thinking behind this approach by sharing a question behind every design decision:

Does this (design) approach create a commitment?


David Roussel, also on the same team as Chris, clarified the technical details of exactly how their team implemented this approach. Later in the discussion, he  summarized the different ways others have implemented similar solutions:

I think there at lots of ways it can be done. But just realizing that we needed to be able to re-prioritize releases at the last minute, and that we could do it simply without branching was the big step. The rest is details, but interesting details.

How else have people solved this? So far we've had people mention:

  • dependency injection, with dependencies changed at build time
  • dependency injection, with dependencies overriden based on config
  • plain old config and if statement
  • branch per feature
  • command document, command pattern,
  • and database based command configuration (need a better name for this).

And Joshua Kerievsky added the following solution to the list:

David - we sometimes ship Commands to production that are still WIP, so no User will see them, yet we can execute them via a URL. Latent Commands?

I'm not sure if your list above includes the simple technique of just making a menu option invisible.

This design technique (or architecture if you prefer) is not new. In fact it pre-dates Agile software development and has many roots in the object oriented and patterns communities. The requirement it is fullfilling, i.e. Chris' question:

Does this (design) approach create a commitment?

is new, however.


Rate this Article