Goodhart's Law
Introduction#
In 1975, economist Charles Goodhart made an observation about monetary policy that would prove remarkably applicable to software engineering. His insight was simple but powerful. When a measure becomes a target, it ceases to be a good measure. This principle, now known as Goodhart’s Law, explains why so many well intentioned metrics programs in software teams end up producing the opposite of what they intended.
The Law Defined#
Goodhart’s Law states:
“When a measure becomes a target, it ceases to be a good measure.”
The formulation is deceptively simple. A metric that effectively measures something when people are not optimizing for it becomes useless the moment you make it a goal. The measurement itself changes the system it is measuring in ways that corrupt the signal the metric was supposed to provide.
In software engineering, we see this pattern repeat constantly. Test coverage percentages become targets, and teams write tests that execute code without testing behavior. Story point velocity becomes a goal, and teams inflate estimates to show artificial productivity gains. Lines of code becomes a metric, and verbosity gets rewarded while clarity gets penalized. Commit counts become visible, and developers split meaningful changes into theatrical micro commits.
The law does not say metrics are useless. It says they become useless when you turn them into targets. The distinction matters because it reveals both the value and the danger inherent in measurement.
Why This Happens#
The mechanism behind Goodhart’s Law is rooted in human behavior and system dynamics. When you measure something, you create information. When you make that measure a target, you create pressure. That pressure changes how people interact with the system in ways that optimize for the metric rather than the underlying goal the metric was supposed to represent.
Consider test coverage. The underlying goal is code that behaves correctly and continues to behave correctly as it changes. Test coverage percentage is a proxy measure for that goal. It correlates with good testing practices when teams are focused on writing tests that verify behavior. But the moment you set a coverage target, the correlation breaks down. Teams can hit 100% coverage by writing tests that execute every line without asserting anything meaningful about behavior. The metric goes up. The underlying goal, code that behaves correctly, gets no closer.
This is not a failure of the metric itself. Coverage percentage is useful information when you are trying to understand which parts of your codebase lack tests. It becomes useless when you turn it into a target because the pressure to hit the number is easier to satisfy by gaming the metric than by achieving the underlying goal. Writing meaningful tests is hard. Writing tests that execute code is easy. When success is defined by the metric, people rationally choose the easier path.
The same pattern appears everywhere you look. Story points exist to help teams estimate relative complexity and plan work. They work reasonably well when teams estimate honestly, trying to predict effort. They fail immediately when management starts measuring velocity and expecting it to increase. Teams inflate estimates on new work and deflate them on completed work. The metric shows improvement. The actual delivery speed does not change, or worse, it declines because teams are now spending time gaming estimates instead of delivering features.
Goodhart’s Law does not require malice or laziness. It simply requires that people respond rationally to the incentives you create. If you reward the metric, people will optimize for the metric. If the metric is not perfectly aligned with the goal, that optimization will come at the expense of the goal itself.
The Measurement Paradox#
The paradox at the heart of Goodhart’s Law is that the things most worth achieving are often the hardest to measure directly. Code quality, team effectiveness, architectural integrity, these are real and consequential, but they resist simple quantification. So we reach for proxies. Lines of code, commit frequency, test coverage, velocity, deployment frequency. These proxies work as signals when people are focused on the underlying goals. They fail when they become the goals themselves.
This creates a genuine dilemma. You need some way to understand whether you are making progress. Metrics provide that visibility. But the act of measuring creates pressure to optimize for the measure rather than the outcome. The solution is not to abandon measurement. It is to use metrics as instruments rather than targets, as information that informs judgment rather than replacing it.
When I look at test coverage, I am not asking whether we hit a percentage target. I am asking whether the coverage we have is protecting us from regressions in areas that change frequently and matter to the business. A system with 60% coverage focused on critical paths is better than a system with 95% coverage spread uniformly across code that rarely changes. The metric informs the conversation. It does not replace judgment about what actually matters.
When I look at deployment frequency, I am not asking whether we deployed more times this week than last week. I am asking whether our ability to deploy reflects genuine confidence in our testing and architecture, or whether we are just splitting releases into smaller chunks to hit a number. Frequent deployments driven by solid engineering practices indicate healthy delivery capability. Frequent deployments driven by pressure to increase the metric often mask growing risk and declining quality.
The shift from target to instrument is subtle but consequential. Targets create pressure to optimize for the metric. Instruments create information that helps you optimize for the goal. The metric stays the same. The way you use it determines whether it helps or hinders.
Using Metrics Carefully#
The real challenge is not avoiding metrics. It is finding metrics that align with your actual goals, where optimizing for the metric means achieving what you care about. These metrics exist, but they are harder to find and often harder to measure than the convenient proxies we tend to reach for.
A good metric remains useful even when people optimize for it. Mean time to recover from incidents, for instance, stays meaningful because reducing it requires building real resilience into your systems. The behaviors that improve this metric genuinely improve your ability to respond to failures.
The problem is that the metrics which truly align with your goals are often difficult to measure directly, especially in software engineering. How do you measure code quality? Team effectiveness? Architectural integrity? These things are real and consequential, but they resist simple quantification. So we reach for proxies. Test coverage for quality. Velocity for productivity. Deployment frequency for delivery capability. These proxies can provide useful signals, but they are easy to game and the moment they become targets, the gap between the metric and the goal becomes a liability.
This is why poor proxies are so prevalent. They are easy to measure. They generate clean numbers. They feel objective. The fact that they can be gamed, that optimizing for them does not optimize for the underlying goal, gets discovered only after the damage is done. By then, the metric is often entrenched in planning processes, compensation structures, and organizational identity.
The discipline required is to constantly ask whether optimizing for a metric actually serves your goals. If it does not, the metric can inform but it cannot direct. You need judgment, context, and a willingness to accept that the most important things often cannot be reduced to a number on a dashboard. When you do find a metric that truly aligns, one where gaming it is indistinguishable from succeeding, you have found something valuable. Until then, treat your metrics as instruments for understanding, not as substitutes for judgment.