Branching Workflows

## What the gate is Every branching model has a moment where a change stops being one person's work and becomes everyone's: the moment it lands on the shared mainline. A **change-review gate** is the checkpoint a team places at exactly that moment. The author publishes the proposed change, automated checks run against it, at least one other engineer reads it, and only when both the machine and the human agree does the change join the line the rest of the team builds on. Two things follow from stating it that way. The gate belongs to the *integration* step rather than to the writing step, which is why its shape changes with the branching model. And its cost is paid in **waiting**, because a published change that nobody has read yet is finished work that is not yet integrated. ## What a review actually buys It is tempting to describe review as bug-hunting and then conclude that good automated checks make it redundant. Four distinct things are bought, and only the first is defect-finding: - **Defects a machine has no model of.** Tests confirm the code does what its author believed. They cannot tell you the author solved the wrong problem, missed a case nobody encoded, or changed a behaviour another team depends on. - **Shared knowledge.** After a review, at least two people know that code exists and why it is shaped the way it is. On a small team that is the cheapest available insurance against one person being the only one who understands a subsystem. - **Design pressure while it is still cheap.** Naming drift when it is forty lines costs a conversation. Naming it after two months of building on top costs a rewrite. - **A durable record.** The review thread is where the reason a tradeoff was accepted gets written down, and it outlives the people who accepted it. The corollary is that a review spending its attention on what a machine already checks (formatting, ordering, a naming convention an automated check can enforce) is a review wasting the only scarce thing it has. ## Size dominates everything else The strongest lever on whether a review finds anything is the **size of the change**, not the seniority of the reviewer or the number of approvals required. | Change size | What a reviewer really does | Typical outcome | |---|---|---| | A few dozen lines | Reads every line, questions intent | Substantive comments, design pushback | | One to a few hundred lines | Reads carefully, skims the mechanical parts | Most real defects still surfaced | | A thousand lines and up | Skims structure, trusts the tests | Approval with few or no comments | Teams commonly place their too-large limit somewhere in the low hundreds of changed lines. Treat that as a working convention rather than a measured law: the honest claim is directional, that attention degrades as size grows, and the precise number is contested. The practical consequence is the same either way. When reviews on a team have become rubber stamps, the cause is usually batching, not laziness, so the useful question is what forces changes to arrive large. Long-lived lines of development, a gate people avoid because it is slow, and work that has no way to ship half-finished all push size up. ## Latency is the other half of the cost A published change waiting for a reader is inventory. It cannot be built on, it drifts further from the mainline every hour, and its author has usually started something else, so the eventual comments arrive against code they have paged out. A nine-engineer car-insurance renewals team on a six-week release cadence measured a median wait of 31 hours for a first read, with 11 changes open at once. Nothing about that number is a review-quality problem. It is a flow problem that surfaces as review quality, because authors respond to a slow gate by making fewer and bigger changes so they pass through it less often. The levers are unglamorous and they work: 1. **Shrink the unit.** A change that can be read in one sitting gets read. 2. **Set an expectation, not a rule.** A first read within one working day is a commitment the team can measure and visibly miss. 3. **Automate the mechanical.** Every check a machine can make is attention returned to judgement. 4. **Grade the gate by risk.** A change to how a renewal price is computed and a correction to a log message do not deserve the same ceremony. ## Where the gate is not the answer Review is a means, not the goal. Teams that pair or work as an ensemble have already had the second pair of eyes, in real time and with more context than a later reader gets, and bolting an asynchronous gate on top of that buys little except delay. Equally, the gate cannot rescue a change that should never have been allowed to grow that large: the fix there is upstream, in how the work was sliced.