The Misleading-Metrics Graveyard

Part 12 set the rules for who sees which numbers, but it assumed something optimistic: that the numbers deserve an audience at all. Some do not. Every estate I have worked on carried at least one metric that had died years earlier and was still being reported — embalmed in a monthly deck, nodded at in reviews, occasionally used to make an actual decision. This part is the tour of that graveyard: eleven metrics, why each one died, and — carved on every headstone — the single line naming what to look at instead. The deaths sort into three causes, and the causes are more instructive than the corpses.

Killed by Goodhart

The largest section of the graveyard belongs to activity metrics — numbers that count motion and were promoted, somewhere along the way, into measures of value. Part 1 explained the mechanism: the moment a proxy acquires consequences, people optimise the proxy and the correlation dissolves. Activity metrics die of this faster than any other kind, because activity is the easiest thing in software to manufacture on demand.

Lines of code — per sprint or per developer. The founding member of the graveyard. It measures volume, and volume was never value: more code is more surface to maintain, more places for defects to live, more reading for the next person. It was a bad productivity proxy when humans typed every line, and now that code is cheap to generate it is not a proxy for anything at all. Instead: throughput of completed work items, with cycle time alongside.

Story points delivered. Points are a planning instrument — team-relative, deliberately abstract, and useful precisely because they are not comparable across teams or time. Reported upwards as productivity, they die instantly: estimates inflate, the “velocity” climbs, and nothing about delivery has changed except the exchange rate. Instead: throughput and predictability, which cannot be improved by re-labelling the same work.

Number of PRs merged. Trivially gamed by slicing work thinner: ten one-line PRs beat one substantial change on this scoreboard while delivering less and costing more review overhead. Instead: cycle time for the whole change, and review quality signals rather than review counts.

Raw commit counts. The same corpse in different clothes — an activity number that rewards habit and tooling, punishes people who squash and think, and says nothing about what any commit contained. Instead: nothing. This one has no replacement because the question it pretended to answer was never worth asking.

Hours logged. Measures presence, not output, and actively penalises the engineer who solves in two hours what the metric would have preferred to see take ten. Worse, it teaches people that visible busyness is the job. Instead: outcomes — anything from part 12's executive page — because the board should not care how long the work was in the oven, only what came out.

Individual velocity comparisons. The most corrosive stone in this section. Velocity is a team-level signal; pointed at individuals it becomes a ranking, and a ranking built on a gameable number destroys the collaboration it claims to measure — why pair, why review carefully, why help, when helping lowers your score? This is part 1's rule in its sharpest form: a metric can inform a decision or judge a person, never both. Instead: team-level trends, and management judgement doing the job it was always supposed to do.

Killed by queueing theory

One headstone stands alone, because what killed it was not gaming but arithmetic.

Utilisation rate. The intuition — busy engineers are productive engineers, so drive utilisation towards one hundred per cent — is precisely backwards, and part 9 showed the mathematics that inverts it. A system running at full utilisation has no slack to absorb variability, so queues grow without bound and everything in them waits: cycle times stretch, unplanned work has nowhere to land, and improvement work never starts because nobody has an idle hour to start it in. High utilisation does not maximise throughput; past a point it destroys it. The metric dies not because people game it but because optimising it honestly makes delivery worse. Instead: WIP and flow efficiency — measure the queues, not the busyness that feeds them.

Killed by time and fashion

The third section holds metrics that were reasonable in their era and quietly outlived it. Nobody gamed them to death; the codebases changed underneath them.

Comment ratio. Born when documentation lived interleaved with code and more of it seemed self-evidently better. In practice a high comment ratio is as often a symptom as a virtue — prose compensating for code that cannot explain itself — and the ratio cannot tell the two apart. Instead: the understandability signals from part 2 — cognitive complexity and the naming the comments were apologising for.

Depth of inheritance. A genuinely useful warning light in the deep-hierarchy object-oriented era, when frameworks encouraged towers of subclasses and a change at the root rippled through every floor. Modern design leans on composition, and shallow hierarchies are now the norm rather than an achievement worth measuring. Instead: the coupling and cohesion instruments from part 4, which measure the dependency problem DIT was always squinting at.

Fan-in and fan-out counting. Not wrong, just superseded — afferent and efferent coupling give the same structural insight with cleaner semantics, and instability built from them positions a module on the main sequence, which raw fan counts never could. Instead: Ca, Ce and instability, as in part 4.

The Maintainability Index, standalone. Part 3 performed the full autopsy: logarithmic compression means dramatic changes in a function's complexity move the composite by a handful of points, so the single number stays reassuringly green while the code underneath degrades. As a coarse first-pass screen it still earns its keep; as a quality gate or a reported KPI it is a sedative. Instead: the components it compresses — complexity and size trends — plus the debt ratio when a single business-legible number is genuinely required.

Reading the epitaphs

Eleven stones, three causes of death, and a pattern worth carrying out of the cemetery. The Goodhart section died of being activity — countable motion mistaken for value, and manufacturable the moment it was rewarded. Utilisation died of being locally sensible and systemically wrong. The fashion section died of era — each one calibrated against assumptions about how software is built that stopped being true. Which suggests the uncomfortable corollary: some metric this series has recommended will eventually join them. That is not a flaw in measurement; it is why thresholds carry dates and instruments get re-read against their assumptions.

Until then, a one-line test I apply to any metric proposed for a dashboard, mine included: if this number doubled overnight, would you know whether things had got better or worse? For cycle time, you know. For escaped defects, you know. For lines of code, PRs merged, hours logged or story points delivered, you genuinely cannot say — and a number whose direction you cannot interpret is not a measure, it is decoration. The graveyard exists because decoration, given a scoreboard and a year, becomes theatre.

There is one force reshaping this cemetery faster than any before it — the same one that turned lines of code from merely misleading into meaningless, and it is not finished. The final part: what AI changes about measurement.