I’m driving 80 MPH through South Dakota – heading to pick up my son from his first semester at college. As I drive I wonder how he’ll remember to grab all his belongings. I wonder if he’ll use a checklist. Will he remember to grab all his charging cords? Will he throw away all his food? Will he remember his laptop? A “Departure Checklist” would help make sure he doesn’t forget anything before disappearing for two months.
I miss checklists.
At my last job, our engineering manager, Marcos, created an elaborate release checklist for each software release. It included items for each day of the release week. Monday: make the release branch; deploy to staging. Tuesday: Create documentation of new features. Wednesday: Manually test edge cases. Thursday: resolve any broken tests, make go/no-go decision. Friday: deploy the software.
We don’t use checklists at my current job. We do continuous delivery. It’d be more accurate to describe it as incremental releases. Probably every couple of days we release to production.
Over my career, I’ve worked with a variety of software delivery vehicles. I’ve built packaged Windows 8 apps delivered via the Windows app store. I’ve built CD-ROMs that we mailed to customers. I’ve had projects deploy to production every time a commit is pushed and merged. All of these are different variations on a software release.
The software release is a form, like a mold or cast, you fill with all the creativity written into the software since the last release. In Wendell Berry’s essay titled “Poetry and Marriage” he says, “Forms join the diverse things that they contain; they join their contents to their context.”
So how does this all apply to continuous delivery?
With continuous delivery you release software as soon as it is considered done. You build tooling to ensure that items on your checklist are handled automatically as you go along. This reduces the risk in the release. But it also reduces the value. Software is only one part of the release.
Continuous delivery does reduce risk. It also forces you get more disciplined with your release steps. These are important aspects of moving toward continuous delivery.
Kent Beck, inventor of Extreme Programming and one of the original signers of the Agile Manifesto, says, in his talk “Software G Forces”, there are many things you learn by increasing your release cadence. As you move from monthly to weekly releases you need to add more automated testing. You effectively remove the need for a separate test team because of the overhead of the feedback cycle. All of this learning is critical to making better software for your customers. You learn what it feels like to deploy immediately. You learn to live with a certain level of anxiety. Or you learn to build infrastructure to reduce that anxiety. But it’s the learning that’s valuable, not the speed up itself.
Software developers tend to think all the value in a release is packed up in the software alone. This isn’t true. There is value in documentation. Value in packaging. Value in release notes. Value in training. Value in marketing copy explaining why it matters. Value in the energy from launch parties. All of these other activities are part of the vessel, or form, of the release. That vessel is the form for the software and all it’s conjoined parts fill. That vessel demonstrates the possibility to a wide audience.
Continuous delivery undermines the form.
A more structured form of a release generates more value from the waiting. The time you pause before the release increases the value. Like compound interest. Berry notes, “Forms join us to time, to the consequences and fruitions of our own passing.”
At my job where we used checklists for each release we moved towards separating the launch – the code deployment – from the release. The release is when you reveal the customer-facing new features. This allowed us to demonstrate more value to customers by packaging up software, release notes, videos, training, and documentation into a single event for customers.
By all means push your team towards continuous delivery. That’s the best way to learn about the friction in your software cycle. But don’t use continuous delivery as a form of software release for your customers.
Berry rightly points out what the form offers, “The forms acknowledge that good is possible; they hope for it, await it, and prepare its welcome — though they dare not require it”
Post a Comment