False efficiency in software

The factory gave us a way to measure work that feels obvious: more output is more progress. Count the units. Count the tickets closed, the bugs fixed, the commits shipped, the story points burned down. A team that produces more is doing better than one that produces less.

In software, that measure can quietly lie.

A software system is not a line producing identical units. It is a living model of a business, and every change either makes the next change easier or makes it harder. So a team can produce a great deal — close many tickets, fix many bugs, ship many commits — while the thing that actually matters, the cost of making the next change, climbs every quarter. Everyone is busy. The burndown looks healthy. And the product moves slower than it did a year ago.

Busyness made of repair work

Here is how it happens, and it is no one's fault in particular. A change goes in under time pressure without a clear home. It works, and it ships. A month later it interacts with something nobody connected it to, and produces a bug. Someone fixes the bug — fast, locally, under pressure again — and that fix quietly sets up the conditions for the next one. Repair becomes a permanent category of work. The team is fully occupied, and a large share of the occupation is cleaning up the consequences of earlier work that was done without a place to put it.

From the inside, this looks like productivity. People are solving real problems all day; nobody is idle. From the outside — from the founder's chair, watching a one-line change take three weeks and a round of testing nobody quite trusts — it looks like a system that has become expensive to touch. Both views are accurate. The busyness is real. It is just made of repair, not of new capability.

Bugs are often the system talking

The instinct, when bugs multiply, is to fix them faster: more hands, more hours, a stricter review process. Sometimes that is the right call. Often it treats the symptom and leaves the cause running.

Because a bug is frequently not a random local slip. It is the system expressing its structure. A business rule that lives in three places will eventually be changed in only two of them. A field that means one thing on one screen and something subtly different on another will eventually be read by code that picks the wrong one. A failure that disappears into a log nobody reads will eventually be discovered by a customer instead. When the same kind of bug keeps recurring, that is not bad luck and it is not a careless team — it is a property of the system, telling you where a responsibility has no clear owner.

Fixing those bugs one at a time, faster, does not change the property. It keeps the repair queue full and the team convinced it is making progress.

The better question

So the useful question is not "how many bugs did we close this week?" It is "why does this system produce so much repair work?" — and then, one class of problem at a time, removing the condition that made the class possible. A rule given a single home. A field given one meaning. A failure given a surface where it shows up on its own, before a customer finds it.

That is the difference between motion and progress. Real efficiency in software is not how much code enters the system; it is how much stable capability the system gains without raising the cost of the next change. A change that adds a feature and leaves the next change more expensive has bought motion. A change that adds the same feature and leaves the next change cheaper has bought progress. On a burndown chart the two are indistinguishable — which is exactly why the chart is the wrong instrument.

The honest limit: not every bug is structural, and not all repair is waste. Some bugs are just bugs. Some systems are about as coherent as they need to be, and the right move is to ship and move on. The signal is not a single bug — it is a class of bug that keeps returning while the cost of change rises and the team stays busy.

What this has to do with ownership

This is the work I am actually paid for when I own a system. Not to close the most tickets — to ask, of each recurring problem, what missing boundary or scattered rule made it possible, and to reshape that part so the whole class becomes less likely. The measure I hold myself to is not throughput. It is whether the cost of the next change is bending downward.

That measure has a name in how I work — quality of change — and it sits at the centre of the values the work is built on. It is also why one focused owner can outrun a larger, busier effort on an unclear system: not by producing more, but by making the system stop producing so much to repair.