Small batches, or nothing else matters

In June 2009, John Allspaw and Paul Hammond gave a talk at Velocity called "10+ Deploys Per Day: Dev and Ops Cooperation at Flickr."

The number in the title was doing the provocation. At the time a great many serious engineering organisations deployed once a fortnight, on a Thursday, with a rollback plan and a conference bridge open.

Sixteen years on, the argument is won on paper and lost in practice at a surprising number of companies.

People agree that small batches are better. Then they spend the quarter shipping a redesign.

If you change one mechanical thing about how your organisation works, change this one. Everything else gets cheaper afterwards.

Why big batches fail out of proportion to their size

A change ten times larger is not ten times riskier.

Worse than that, for four reasons that stack.

First, diagnosis.

A deploy containing one change breaks production and you know what broke it. A deploy containing forty changes breaks production and you have a research project. At 2am. With an audience.

Second, merge cost.

Branch lifetime and merge pain rise together, and not linearly, because the codebase underneath keeps moving. A branch that lives six weeks is negotiating with six weeks of other people's work.

Third, feedback delay.

Every large batch is a bet placed a long way before the results arrive. Ship weekly and you're wrong for a week. Ship quarterly and you're wrong for a quarter, having built three more things on top of the wrong thing before anybody finds out.

Fourth, political weight. The one nobody plans for.

A big release accumulates stakeholders. By the time it's ready, four teams have made commitments depending on it, somebody told a customer a date, and marketing has a landing page. Cancelling it is now a social event rather than a technical decision.

Large batches convert reversible choices into irreversible ones. Precisely backwards.

The four things that push batch size up

Batches don't grow because people prefer them large.

They grow because something in the system makes small ones expensive.

Deploys that cost something. If shipping requires a human to run a checklist, batching is rational, because anyone will amortise a painful step across more work.

The fix isn't discipline. It's making the step cheap.

Coupling. When a change to the billing module requires a coordinated change in three other services, batch size is set by the architecture, not by choice. This is the expensive one to fix and the one most often misdiagnosed as a process problem.

Approval. Every gate adds latency, and latency makes people queue work behind it.

A change advisory board meeting on Wednesdays sets your minimum batch size to one week, whatever your CI pipeline can do.

Fear. Sometimes there's no structural reason at all and the team simply doesn't trust the deploy.

Usually a specific incident. Often years old. Often involving somebody who has since left. This one is real, and it responds to evidence rather than to argument.

Look at your own organisation and you'll find at least two of the four.

Fix them in this order: cost, fear, approval, coupling. The first two are cheap, and they buy the credibility to do the last two.

Deploying is not releasing

The single most useful idea here is that putting code on a server and exposing behaviour to users are separate events that most teams have welded together.

Once you separate them, a half-finished feature can live in production behind a flag for three weeks while it's being built. There is no long-lived branch. There is no integration week. The team merges to main most days, the code is continuously proven against real infrastructure, and the release becomes a configuration change made by whoever owns the decision.

This costs something. Flags accumulate, and a codebase with two hundred stale flags is its own kind of mess. Budget for removal in the same ticket that adds the flag, and audit them quarterly. It is still a far better problem than the one it replaces.

What actually changes when you ship daily

The obvious benefit is speed. The interesting benefits are cultural, and they arrive without being asked for.

Estimation stops mattering as much, because the unit of work is small enough that being wrong about it costs a day. Planning meetings get shorter. The question "when will this be done" gets replaced by "what's the next thing you'll ship," which is both easier to answer and more honest.

Incident severity drops, because the average change is tiny and rollback is a routine operation rather than an event.

And the relationship with the rest of the business changes character. When engineering ships something visible every few days, trust stops depending on roadmap documents. That trust is what buys you the room to say no later.

Where this argument breaks

I've watched this get applied badly, so it's worth naming the edges.

Firmware, medical devices, anything with a regulatory sign-off, and anything installed on a customer's hardware genuinely cannot ship continuously. Mobile apps have an app store queue in the middle, though the flag technique works there and most mobile teams underuse it.

Database migrations are the honest hard case. Expand-contract works, it's just more thinking per change than developers expect, and teams that skip the discipline learn about it during an outage.

There's also a failure mode where small batches become a substitute for thought. A team ships thirty small changes a week, none of which is connected to a coherent idea about the product, and calls the resulting churn velocity. Batch size is a delivery variable. It has no opinion about whether you're building the right thing, and it cannot rescue an organisation that has stopped asking.

The first move

Don't announce a transformation. Pick the team with the least painful deploy path and ask them to cut their average change size in half for one month, with nothing else changing. Measure lead time before and after.

Then let them tell everyone else. It lands better from them than from you.