Description
Every organisation that adopted a coding assistant changed how code gets written. Almost none changed how it gets integrated. That asymmetry has a name and a cost, and it lives in the gap between the two.
A branch is a bet that the distance between your work and the trunk will stay affordable. Each day it stays open, the trunk moves and the distance grows, and the growth is not linear in effort: conflicts become more likely the longer a branch lives, and code touched by a conflict is more defect-prone afterwards. The studies that establish this also establish what the conflicts consist of. Mostly they are not formatting collisions. They require somebody to reason about program logic, which is the most expensive kind of work to have deferred and batched.
Now change the inputs without changing the strategy. More code arrives per developer per day, more of it is revised shortly after landing, and more of it is duplicated rather than consolidated. Every one of those enlarges the surface on which two branches can disagree. The merge that used to be routine at the end of a sprint becomes a two-day job with real decisions in it, taken by somebody who no longer remembers writing half of what is in front of them.
The organisations that absorb this are not the ones with better merge tooling. They are the ones where a branch cannot get old, because the flags, the fast tests and the policy make integrating several times a day the ordinary thing to do. That is what this dimension scores: not whether you believe in short branches, but whether anything stops one from quietly reaching a month.
The five levels
One question decides which rung you are on: does the system itself act on this, or does a human have to choose to? Each rung carries a tell: the thing that would settle it, so the score is something you checked rather than something you agreed with.
- 1
Blind
Nothing tracks branch age. Work sits on branches for as long as it takes, integration happens near a deadline, and the cost only becomes visible when two changes collide. Nobody can say how much divergence the organisation is carrying right now.
The tellSort the open branches in your busiest repository by their last commit and look at the bottom of the list. If the oldest is months old and nothing anywhere reports that, you are here.
- 2
Tacit
Certain teams integrate constantly because the people on them insist on it, and they suffer few conflicts as a result. Other teams in the same organisation run branches for weeks. The difference is a habit rather than a rule, and it leaves when the person holding it does.
The tellCompare branch ages across your two busiest teams. If one is measured in hours and the other in weeks, and no rule distinguishes them, the practice belongs to people.
- 3
Visible but inert
Branch age is visible. The tooling reports it, somebody raises long-lived branches in a retrospective, and there may be a documented target. Nothing enforces it: a branch can live a month without anything objecting, so the report records the divergence instead of preventing it.
The tellFind your oldest branch, then find what happened when it passed the target. If the answer is that it appeared on a list and stayed there, nothing is acting on the number.
- 4
Acted on
Branch lifetime is bounded by the system. There is a limit and something enforces it: builds that refuse stale branches, flags that make an unfinished feature safe to merge, tests fast enough that integrating several times a day is realistic. Integrating stops being a decision anyone makes.
The tellFind the last branch that crossed your lifetime limit. Something blocked or flagged it automatically, and the flags and fast tests that make short branches survivable were already there rather than merely recommended.
- 5
Durable
The discipline holds under pressure. New repositories arrive with the flags and the fast tests that make short branches possible, the limit is not suspended for a large migration, and exceptions carry a name and a date instead of becoming quietly permanent.
The tellLook at what happened to branch lifetimes during your last big release or migration. Lifetimes that did not move, or exceptions with owners and dates, are durable. A code freeze is the practice being switched off exactly when it was needed.
What this dimension rests on
The five levels are observed, from client engagements, and no paper produced them. What the research below establishes is why this dimension is worth scoring at all. No links: the citations carry enough to find them, and they stay findable after a link would have rotted.
Kasi and Sarma, An Empirical Investigation into Merge Conflicts and Their Effect on Software Quality (Empirical Software Engineering, 2013)
Studied merges across many open source projects and found that conflicts needing human resolution are common, that they become more likely the longer a branch lives, and that code involved in them is more defect-prone afterwards.
Ghiotto, Murta, Barros and van der Hoek, On the Nature of Merge Conflicts: A Study of 2,731 Open Source Java Projects (IEEE Transactions on Software Engineering, 2018)
Characterised what merge conflicts actually consist of and found most are not formatting collisions. Resolving them requires reasoning about program logic, which is the expensive kind of work to defer.
Where this came from
This dimension has a published article behind it, written from client engagements rather than from a greenfield repository.
Read the article on Trunk-based development →
How to climb this dimension is not written yet. It is the next thing this page grows, and saying so is more useful than a paragraph of generic advice.