Ship Small, Ship Often: A Release Rhythm That Survives Real Life
Big releases fail quietly for weeks before they fail loudly. Here is the weekly rhythm I use to keep changes small enough to reason about and boring enough to ship on a Thursday.
Ari Bennett
Software engineer and writer
Every team I have joined had the same story about their last big release. It slipped twice, it went out on a Thursday night, and someone spent the weekend on call. Nobody planned it that way. The release simply grew until it was too large to hold in one head, and once that happens the schedule stops being a plan and becomes a hope.
The fix is not more process. It is a smaller unit of work.
What counts as small
A change is small when one person can explain it, review it in one sitting, and roll it back without a meeting. That is the whole definition. It says nothing about line count, because a two thousand line change that renames a folder is small, and a forty line change to session handling is not.
I test the size of a change with one question: if this breaks at nine on a Monday morning, do I know within two minutes where to look? When the answer is yes, the change is small. When the answer is a long pause, I split it.
The rhythm
My week has one shape and it has not changed in years.
- Monday is for picking a slice thin enough to finish. Not a feature, a slice: one route, one migration, one state that was previously unhandled.
- Tuesday and Wednesday are for building it, behind a flag if it touches anything visible.
- Thursday is for shipping it, reviewing what shipped, and writing down anything surprising.
- Friday is for the boring work that makes next week faster: deleting dead code, fixing the flaky test, updating the one document everybody actually reads.
The point is not the specific days. The point is that shipping happens on a schedule I do not renegotiate. When a slice is not ready by Thursday, the slice was too big, and that is information worth more than a heroic push.
Flags before branches
Long-lived branches are how small changes turn into big ones. Code sitting outside the main line ages badly: the tests around it drift, the assumptions rot, and merging becomes archaeology.
I put unfinished work behind a flag and merge it the same week. The feature is invisible to everyone but me until the last change, which usually deletes the flag. The reason this works is not technical. It is that the cost of the work stays visible the whole time, instead of arriving in one bill at the end.
Anything that cannot be merged this week is not a task. It is a project pretending to be a task.
When it breaks anyway
Small changes still break things. The difference is what happens next. With a week of separate slices behind you, the list of suspects is short, the difference is readable, and the rollback is one action.
Keep a simple record of what shipped and when. Not a formal changelog for users, just a running list with the date, the change, and one line about anything odd. I have solved more production problems by reading three lines of my own notes than by reading dashboards.
The part that is actually hard
None of this is difficult to understand. It is difficult to keep doing when a deadline appears, because the instinct under pressure is to batch: hold the changes, ship them all at once, save time on the release itself.
That instinct is backwards. Batching does not remove the work, it removes your ability to see it. Every large release is a bet that nothing inside it interacts badly with anything else, and you always place that bet at exactly the moment you have the least time to check.
Ship the small thing. Then ship the next one.
Written by
Ari Bennett
Software engineer and writer
I build web software for a living and write about the parts that are hard to search for: the trade-offs, the dead ends, and the small habits that make a codebase pleasant to come back to a year later. A decade in, I still keep a paper notebook next to the keyboard.
More about the writer
