When a Measure Becomes a Target

The best engineering dashboard I have ever been shown belonged to one of the worst codebases I have ever worked in. Test coverage sat above ninety per cent. Complexity was green in every module. Velocity climbed gently quarter on quarter, and the quality slide in the steering pack had been three tidy green circles for over a year. Meanwhile releases were feared, hotfixes travelled in convoys, and the two engineers who actually understood the billing module booked their holidays apart by unspoken agreement, the way flight crews eat different meals. Every number on that dashboard was real. Every number was also a performance — measurement theatre, staged weekly for an audience that had long stopped asking what the numbers meant.

This series is about measuring software work without staging that play: which numbers deserve tracking, what each one can and cannot tell you, where its thresholds actually come from, and how to put the results in front of three very different audiences without any of them being lied to.

The law with two authors

The failure mode has a name, and the name has a complication worth getting right. Charles Goodhart made the underlying observation in 1975; Marilyn Strathern, in 1997, distilled it into the sentence everyone now quotes — “When a measure becomes a target, it ceases to be a good measure.” The famous wording, in other words, is Strathern's formulation of Goodhart's law, and it deserves both names attached whenever it is wheeled out. It gets wheeled out a lot, usually after the damage.

What the law describes is not dishonesty. It is adaptation. A metric is useful precisely because it correlates with something you care about but cannot observe directly — coverage stands in for test rigour, cycle time stands in for delivery health. The moment the metric acquires consequences, people quite reasonably optimise the metric, and the correlation it depended on dissolves under the pressure. Nobody has to cheat. The number just quietly stops meaning what it meant, while continuing to look exactly the same on the slide.

The theatre repertoire

I have watched every act in this repertoire performed live, and none of them required a bad actor.

Put a coverage target in the quality gate and tie it to appraisal, and within two sprints you will find tests that execute code and assert nothing — green ticks purchased at the cost of false confidence. Turn a complexity threshold into a judgement of the author rather than a property of the code, and functions get split into trivially decomposed fragments that satisfy the gate and are harder to follow than the original, because the complexity moved into the call graph where no metric was watching. Make deployment frequency a scoreboard and empty deployments appear. Make cycle time a scoreboard and work items shrink and split until the average flatters. Count lines or commits and you will receive lines and commits, in abundance.

Notice what these have in common: in every act, the instrument was fine and the aiming was wrong. Which gives this series its first and most load-bearing rule of thumb: a metric can inform a decision or judge a person — never both. Everything else in the next thirteen parts is commentary on that sentence. Metrics in this series are diagnostic instruments, pointed at systems; the moment one points at an individual, expect it to start lying within the fortnight.

What this series measures, and what it refuses to

The plan covers both halves of the measurement problem. The first half is the code itself: complexity metrics and which of the two headline ones deserves your merge gate, the maintainability index and the debt ratio, coupling and cohesion at architecture level, test effectiveness beyond coverage, churn and hotspots, and vulnerability metrics treated as an operations discipline rather than an annual scare. The second half is delivery: DORA's five metrics — current and correctly dated — flow metrics and the queue mathematics beneath them, the SPACE framework's human dimensions, the mechanics of capturing all of it in Azure DevOps, and reporting that respects its audiences.

Just as firmly, here is what the series will not do. It will not measure individuals; every number here is a team- or system-level instrument. It will not rank your teams against each other — DORA itself warns against cross-team comparison, and that warning survives contact with practice. It will not compress quality into one number, because part 3 shows in some detail what single numbers hide. And it will not hand you a red-amber-green rollup as a substitute for understanding; where a RAG rating earns a place, the underlying data rides along with it.

A word about register, because this series mixes two kinds of authority and I want the seam visible. The named frameworks — Thomas J. McCabe's cyclomatic complexity, SonarSource's cognitive complexity, the maintainability index, Robert C. Martin's main sequence, the DORA research programme (founded by Nicole Forsgren, Jez Humble and Gene Kim, now part of Google Cloud), Scaled Agile's flow metrics, the SPACE framework — are other people's work. I write about them as credited synthesis: inventors named in prose, definitions checked against primary sources as I write, trademarked material paraphrased rather than lifted. The stacks, gates and thresholds I recommend — which metric blocks a merge, what level of churn triggers an investigation, what a quarterly health review actually contains — are my own practice, built and revised across estates I have worked on. When you meet a threshold in this series with no citation next to it, that is deliberate: it is mine, offered as a tested default rather than as industry law, and you should adjust it against your own context the way I did against mine.

Why measurement stopped being optional

There has always been a case for measuring code; what has changed is the cost of not doing so. As of early 2026, surveys — Sonar's State of Code among them — put AI-assisted code at roughly forty per cent of committed code, with vendors projecting majority share. Whatever you make of the projections, the direction is not in dispute: more of what lands in your repository was generated quickly, reviewed under time pressure, and shaped by a tool with no memory of your architecture. When code is cheap to produce, activity metrics inflate on their own and quality signals are the only part of the dashboard still connected to reality. The final part of this series takes the AI question head on; every part before it is made more urgent by it.

That is the stake. The craft is knowing each instrument well enough to read it without being played by it — and that is a metric-by-metric job, which is why this is fourteen parts and not a listicle.

Where the series goes

1. When a Measure Becomes a Target — this post: the law, the theatre, and the rules of engagement.
2. Cyclomatic Counts Paths, Cognitive Counts Pain — two complexity metrics that look interchangeable and answer different questions.
3. The Maintainability Index and the Debt Ratio — the composite that hides and the ratio that translates.
4. Coupling, Cohesion and the Main Sequence — measuring the lines between the boxes, with Robert C. Martin's distance metric.
5. Coverage Is Not Testing — the most gamed number in engineering, and the mutation score that keeps it honest.
6. The Files That Keep Changing — churn, hotspots and ownership spread.
7. Vulnerability Metrics Are an Operations Discipline — density, remediation time and review coverage, run like operations rather than audit season.
8. Five Metrics, Not Four — DORA as it stands today, with every figure dated to its report year.
9. Flow Metrics and Little's Law — the queue mathematics underneath delivery, and Scaled Agile's six flow metrics.
10. SPACE and the Human Dimensions — why no single metric captures productivity.
11. Capturing It All in Azure DevOps — widgets, Analytics, OData, and the gaps between what the platform gives you and what you need.
12. Reporting to Three Audiences — the team, the team lead and the stakeholders, without RAG theatre.
13. The Misleading-Metrics Graveyard — the numbers to stop reporting, and what killed each one.
14. What AI Changes About Measurement — the retrospective, and the metrics that matter more now.

If your quality gate is a coverage percentage nobody believes, or your quarterly review opens with three green circles nobody questions, the next thirteen parts are for you.