Sometimes I’m writing something for work and it’s true, but it’s too silly to put on a corporate blog. Good thing I have a personal blog!
Definitions
Continuous Delivery, according to Martin Fowler, is
a software development discipline where you build software in such a way that the software can be released to production at any time
Ok, cool. And Continuous Deployment is when you actually do push to production all the time and it’s easy because you have automation. And Continuous Integration is when you have a software lifecycle that promotes Continuous Delivery by automating everything. Got it? Good.
Fowler, in the above definition, says “released to production”, and that’s where I disagree with him. It can be pushed to production, it can be delivered to production, but release? Release is the moment people get value. It’s the contact surface of software, where humans start using it to do something. Release is not something we can do buy building software, someone has to adopt it, at least a little bit.
The metaphor
It has been…several decades since I planned a wedding, and mostly I found it stressful and eloped. Nonetheless, I am ambiently exposed to wedding planning, and it reminds me a lot of the software development lifecycle. Here, I’ll make you a table.
A wedding table, with fancy white fabric, a bouquet that is at least partially printed pages, a custom coloring book, and scattered petals.
Wedding planning/software development
| Wedding | Software | |
| Budget | Strictly scoped, likely exceeded | Moderately scoped, exceeded |
| External Stakeholders | In-laws, wedding planners, paying parties | Sales, process coaches, finance |
| Marketing | Wedding-industrial complex, people who want an open bar | Analysts, VPs, investors, people who want an open bar |
| Process | Civil and religious authorities, cultural expectations, things you saw on Instagram | Consultants, cultural expectations, things you saw on LinkedIn |
| Outcome | Married couple, pictures | Usable software, promotions |
You know what has almost nothing to do with either wedding planning or software deployment?
Life the next day.
You wake up, and you’ve released software, or you’re married, and that is all behind you but the debt. The whole process you were so stressed about, every time you rewrote a seating chart or re-organized an information flow, it’s over. It was absolutely important, but now it isn’t.
What’s important now is living together. For married couples, it’s accepting that the person you’re legally and financially tied to puts hot sauce on their potato chips. For software, it’s accepting that no matter how much you tried to make it obvious, someone is going to hold it wrong, use it weird, ignore the updates, or otherwise be wrong about it. And that you can’t really do much about it. Because the way they’re using it is the best way they know how.
Release
It’s an evocative word, release. It makes you think of letting go of balloons and taking fish off hooks and a small child riding away on a wobbly bike. It makes you think of endings and next stages and life after imprisonment and all sorts of fluffy things.
Yeah, that’s not how it is in software, at least not anymore.
Software release is more like when you accidentally hit a wasps nest with your rake and you have released their wrath. The first thing that happens is that you have disrupted a previously acceptable status quo. The second thing that happens is that everyone shoots out of their comfy nest, looking to figure out what’s going on and why anything changed. And the third thing that happens is a lot of exploration of the new situation. Sometimes to the detriment of the original change agent.
But that’s maybe too distressing. Let’s go back to the marriage after wedding.
How do the two of you work together? Can the user get the software and its people to understand a particular industry workflow requirement? Can the software get the users to store credentials in a more secure way? What are the affordances and what are the problems? If there’s a big problem, is it a divorce-level problem, or could it be solved by a rollback to a previous good state?
The ongoing relationship between software creators and users is the state of being released, and it deserves care and attention that is very different than that we expended on the wedding/deployment.
Is planning a wedding a huge logistical feat? Sure. It’s impressive. And it deserves the attention we spend on it, because it’s the biggest moment in your life together so far. But there’s a lot of living together after that.
The difference between weddings and deployments is that we are encouraged to plan multiple deployments – small, frequent, non-disruptive. They should be the Tuesday date night of the software world – a favorite restaurant, a sitter you trust, whatever movie is showing. Predictable, but affirming.
Conclusion
It’s a silly metaphor, and there are always problems with extended riffs, but this has made me think about how easy it is for us to emphasize the single point in time of deployment, and not the hopefully long and trusting relationship that comes after release.
If you’d like to keep riffing, here’s the Bluesky thread: