Half of What We Merge Is Repair. That Was a Point on a Curve.

In August, just over half of every change merged across our repositories was a repair. Not a new feature, not a cleanup — a fix. 777 of 1,548, 50.2%. I run a group of companies where the development is done by an automated system rather than by a team of people, and that number felt like the finding: here is what it actually costs to have software written this way.

I nearly published it. What stopped me is worth more than the number, so this piece is about both — what the share really does over seven months, and the mistake I made reading it, which I suspect is the most common mistake there is with a metric like this.

One month is an anecdote, so I took a second

A single month tells you what happened, not how something behaves. So I took a second window — the first days of September — and ran the identical query: same repositories, same classifier, changes merged in the period, counted by the prefix on the title.

It came back higher. Two windows, both around half. I wrote down that these were two independent samples, that the share was therefore a property of the flow rather than a property of August, and moved on.

That conclusion was wrong, and it was not wrong because of a bad number. Every figure in it was correct.

Two adjacent windows prove the method, not the behaviour

The two windows were next to each other. August, then the first days of September. Repeating a measurement on the adjacent period demonstrates that the method returns the same kind of answer on new data. It says nothing at all about whether the thing being measured is moving, because on two points a trend and a constant look identical.

Repeatability is what a second window buys. Stability costs a series. I had bought the first and spent it as though it were the second.

The curve

So I pulled every month from March, on the same two organisations, with the same classifier. Every month is counted the same way as every other, which is the only thing that makes one row comparable with the next; where this run disagreed with an earlier one, that is recorded below rather than reconciled away.

Half is not a level. It is a point the flow passed through on the way up. The trough is June at 22.3%; three months later the first six days of September run at 56.2%, a factor of 2.5. That last point is a six-day window rather than a month, so read it as the direction of travel — the two complete months before it, 34.4% and 50.2%, carry the claim without it. Publishing "about half of what we merge is repair" as a fact about how this works would have been publishing the value of a moving quantity as though it were a constant.

It is not a change of subject

The first thing to suspect is composition: not that more of the work became repair, but that the repositories where repair was always common grew heavier in the mix. That would produce the same curve without anything actually changing.

It does not hold, because the rise happens inside individual repositories and not merely in the mix between them. A longevity product goes from 5.1% of its merges being repairs in May to 24.7% in August. A medical platform goes from 17.1% in July to 51.4% a month later. Neither of those is a change in which repository is busiest; both got quieter over that stretch, not louder.

It is also not a uniform drift dressed up as a finding. An ERP in the same mix moved the opposite way over the same months, 15.3% down to 9.1%. Some things rose, one fell, and the aggregate rose — which is what a real change in the composition of the work looks like, as opposed to a measurement artefact that would move everything together.

The share depends on whose code it is

The split the aggregate hides is the more interesting one. Separate the system's work on its own machinery from its work on the products it builds for other people, and the two behave like different activities:

In August the system spent 77.6% of its merges on its own machinery repairing that machinery, against 30.9% on product code — a gap of 46.7 points. From April onwards the gap is present in every month and never closes; it only widens. March is the exception, and it is inverted there, which is one more reason not to read March with the rest.

Which means the headline "about half" is a weighted average of two quite different regimes, and its value depends nearly as much on how much self-work there was that month as on how much repair there was. That alone disqualifies it as a benchmark for anyone else's flow.

What this does and does not say

It says: the share of repair in this flow rose in every month after June, and it runs persistently higher in code the system writes about itself than in code it writes for a product — 2.5 times higher in August, 1.9 times in the most recent window, and higher in every month from April onwards. That ratio moves too, which is the whole point: quote it with its month attached or not at all. Both halves are measured on the full population, not a sample.

It does not say that more things are breaking. A share is a fraction, and its numerator and denominator move for different reasons. Between July and August the total volume fell by 42% — 1,548 merges against 2,678 — while the count of repairs fell too, by 16%, 777 against 921. Fewer repairs, in absolute terms, and a higher share of them: the share rose because the rest of the work fell away faster. A repair share quoted as a quality metric without both halves of the fraction can be made to say almost anything.

Where the series stops explaining itself

March does not fit. It sits at 42.0% — far above the trough that follows it — and it is high in both halves of the split at once. I do not know why. It could be a different convention for titling changes back then, a different composition of work, or a different way of running the process. I have not established which, so it goes in as measured rather than smoothed away. And the rise I am claiming starts at the June trough, not after March — April, May and June all sit below March, and nothing here explains that either.

If you want to run this on your own history

The method is deliberately crude, because a crude method that anyone can re-run beats a careful one nobody can check:

• Count changes merged in a window, across whatever set of repositories you consider one flow. Merged, not opened — opened work includes what was abandoned.
• Classify by the prefix on the title. If your titles carry a conventional prefix, this is a single string comparison and it is reproducible by anyone with read access.
• Re-run an already-closed window and compare it against what you recorded before. If it does not reproduce exactly, do not proceed until you know by how much and in which direction — mine did not, and finding out how far off it was is the difference between a series and a pile of numbers.
• Then take at least four points before you say the word "trend". Two adjacent windows will happily agree with each other all the way to a wrong conclusion.

The classifier has an obvious hole: a repair titled by what broke rather than by its kind does not land in the count. That makes every share here a lower bound. I would rather publish a floor I can describe than a precise number I would have to ask you to trust.

The part I would keep

The number I started with was true and useless. The number I ended with is smaller in scope and worth something: repair share is not a constant of this way of working — it moved by a factor of 2.5 between June and early September — and in August it ran 2.5 times higher in the code the system maintains for itself than in the code it ships.

And the step in the middle is the one I would keep if I could keep only one. A second measurement that agrees with the first feels like confirmation and is not. It tests the instrument. Testing the world takes a series, and I had to be shown that by my own data after I had already written the conclusion down.