Nothing Ships in August, and Frankly I've Stopped Fighting It
Photo: Tim Marchant, CC BY-SA 2.0, via Wikimedia Commons
Somewhere around the 18th of July, a switch flips across British industry. Change requests get filed under 'September'. Deploy pipelines go quiet. Somewhere in a Slack channel, a well-meaning engineering lead types the words "let's not risk it before the break," and a nation of developers breathes a collective sigh of relief.
The summer code freeze is as British as complaining about the weather while doing nothing about it. And I have a confession: I've stopped being annoyed by it.
The Case Against the Freeze (or: Why Silicon Valley Thinks We're Mad)
Let's be honest about what the freeze is. In California, shipping in August is a Tuesday. Continuous deployment doesn't take a holiday; the machines don't know it's Pimm's season. The American ethos says: if your deploys are scary, that's a you problem — make them smaller, make them safer, ship on.
And they have a point. A team that can only deploy eleven months of the year has a deployment problem, not a calendar problem. Fear-based release management tends to produce exactly the big-bang, all-hands-on-deck releases that everyone dreads, which then justify more freezing. It's a self-fulfilling prophecy with a Gantt chart.
The Case For (or: Why Britain Might Be Onto Something)
But here's what the move-fast crowd misses: August in Britain is when nobody's at work. Your users are in Cornwall. Your support lead is at a wedding in Portugal. Your one person who understands the payment integration is on a narrowboat with, in their words, "patchy signal at best."
Shipping software to an absent audience isn't agility — it's theatre. If something breaks on the 12th of August, your incident response plan is a voicemail and a prayer. The freeze isn't cowardice; it's a rational response to a country that empties out for six weeks.
There's also something to be said for a culture that treats operational risk with respect rather than bravado. Britain's financial institutions, for all their faults, do not have stories about the intern who deployed to production from a beach. That's not nothing.
The Real Waste Isn't the Freeze — It's What You Do Instead
Here's my actual complaint, and it's a narrow one: most teams use the quiet months for a summer refactoring spree that nobody asked for and half of them will abandon by September. If you're not deploying, fine. But don't spend the silence rewriting a service that worked.
The quiet months are a gift, and we keep spending them on the wrong things. Better uses:
- Kill the backlog of small horrors. Flaky tests, terrifying runbooks, that one cron job nobody understands. Not refactoring — documenting, deleting, defusing.
- Do the disaster rehearsal you keep postponing. Restore a backup. Actually restore one. In August, when nobody's watching.
- Talk to a customer. Without a release to prep, someone on the team could ring three users and ask what's annoying them. Revolutionary.
So keep the freeze. Defend it, even. But use it. A frozen pipeline with a team that spent the summer getting genuinely safer is institutional wisdom. A frozen pipeline and a half-finished rewrite of the notification service is just a very expensive August.
Deploy nothing. Learn something. See you in September.