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.

via Instagram http://ift.tt/2FRvEcT
On readable software

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.

Ely Cathedral

via Instagram http://ift.tt/2tLIgLO

Anglesea Abbey

via Instagram http://ift.tt/2pU6eXg

via Instagram http://ift.tt/2p3eLHu
Blank Slates

This New Year, I wish you more blank slates. May you have more blank white pages sitting in front you with your favorite pen nearby and at the ready. May you have blank screens in your code editor with your absolutely favorite color syntax highlighting. May your garage work table be empty save for a single large piece of reclaimed redwood and a saw. – The Builder’s High


via Instagram http://ift.tt/2htOI40

via Instagram http://ift.tt/2gR7S7Z
Is that email important
Best email footer ever? From Protest:

*******************************************************
Disclaimer:

IMPORTANT – In the time it took you to read this email, you could have been out the door and on your way to the slopes or the beach. The good news is, it’s not too late. Slowly shut your computer off. Act like you head toward the restroom. Then make a break for the door. If you don’t look back, the obstacles will never stand a chance. See you out there.

*******************************************************