I’ve spent a lot of time recently looking at how to manage multiple supported code streams. One key question we’ve been discussing is how frequently do you patch a product depending on where in its lifecycle it is? One of the positions was that this discussion has to happen on an ad-hoc basis so that a release is made when sufficient changes have occurred to constitute a patch or an urgent release is needed. While this makes sense for products approaching end of life when changes are few and necessitated by the requests of existing customers, however patching this way for products under active development or even maintenance leads to problems with resource scheduling and awareness.

The solution to this is the release bus. The bus has a fixed cadence, once release per year/half/quarter/month (based on your release tolerance) any fix that is ready to go when that bus is scheduled to released with that bus and anything else must wait for the next one. Buses are easy to schedule, (should) run on time and everyone knows when the bus is going. This sounds fantastic in theory but there will always be an expected change that just needs to be released now, so what gets there faster than the bus? The release taxi, you can go where you want, when you want but it costs more and if we’re paying you will be asked why.

By splitting the patch releases into these two categories its easier to classify scheduled maintenance from one-off changes. If you start to see too many release taxis questions can be made raised as to why these changes are not making it onto the schedule.

There is a great post circulating this week on the definition of readable code and one quote really stuck out at me:

All software gets developed under time, budget, management, requirements, and skill constraints that prevent doing anything perfectly. We should keep those constraints and limits in mind when we look at code and immediately conclude the code resists understanding, or that only fools would have produced such software.

Having moved teams internally I’m in the unusual position of being the ‘fool’ who wrote the software someone else needs to maintain and still being around to explain why it is the way that it is. This has reminded me that when reading a codebase you often only have part of the context and when you are writing how important it is to document your decisions.