Sixty engineers work on branches that live five days on average before merging. Estimate what that lifetime costs per year, and say which assumption dominates the error.

The assumptions, stated

• 60 engineers, each merging roughly 1 branch per week: about 3,000 merges a year across 46 working weeks.
• A branch open for 5 days overlaps with roughly 60 other open branches at any moment (60 engineers × 5 days of overlap divided by a 5-day week).
• Probability that any given branch touches a file another open branch also touched: call it 15% in a typical service-sized codebase, rising steeply with branch lifetime because a longer branch overlaps with more other branches.
• Cost of a conflicting merge: 1-4 hours, including re-testing and the risk of resolving it wrongly.

The arithmetic

3,000 merges × 15% conflict rate = 450 conflicting merges a year. At 2 hours each that is 900 engineer hours, or roughly **\(90,000** at \)100 a fully loaded engineer-hour.

That is the visible cost, and it is the smaller half.

The cost the arithmetic misses

Conflict frequency is superlinear in branch lifetime, not linear. Doubling lifetime to 10 days roughly doubles the number of concurrently open branches and roughly doubles the window in which each can diverge, so the conflict rate rises by considerably more than 2x. Halving it to 2.5 days cuts the cost by more than half.

Then the second-order effects, which are larger than the conflicts:

• Integration risk moves to the end. A five-day branch is five days of untested interaction, discovered at merge, under deadline pressure.
• Review quality falls with batch size. A 900-line diff gets a different quality of review than a 90-line one, and the defects that slip through cost incident time rather than merge time.
• Feedback is delayed. A design mistake made on day one is discovered on day five, after four more days have been built on it.

Which assumption dominates the error

The conflict probability. It varies from near zero in a codebase with well-separated modules and small teams per area, to well over 40% in a monolith where several teams edit the same files. The 15% figure is a placeholder for a number you can measure directly: count merges that required conflict resolution over the last quarter. That single query replaces the whole estimate.

What the number rules in and out

• Rules in: anything that shortens branch lifetime cheaply - a merge queue, smaller work items, feature flags to decouple merge from release. These are weeks of work against a six-figure annual cost.
• Rules in: measuring branch lifetime at all. Most organisations do not, and it is available from the repository in minutes.
• Rules out: changing the branching model as the primary intervention. Branch lifetime is the variable; the model is a convention that influences it. A team on trunk-based development with five-day feature branches has the same costs under a different name.
• Rules out a large investment in better merge tooling, which addresses the symptom while the batch size stays the same.

When this is the wrong analysis

When branches are long because review is slow, not because work is large. Then the cost is queueing and the fix is reviewer capacity or a review SLA; shortening the work items simply produces more branches waiting the same amount of time. Check the distribution of time from first commit to first review before concluding anything about branch size.