Goodhart's Law
debt(d9/e7/b7/t7)
Closest to 'silent in production until users hit it' (d9). Detection_hints explicitly states automated=no. The code_pattern examples (100% coverage with trivial assertions, velocity gaming, bug suppression) only become visible when a human notices anomalies in outcomes — often after significant damage to team culture or product quality. No tool in the detection_hints list can catch this; it surfaces only when the metric diverges visibly from the underlying reality it was meant to represent.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix suggests pairing each metric with a counterbalancing metric, but in practice Goodhart's Law violations are cultural and structural: every process, team norm, performance review, and tooling choice that was built around the gamed metric must be revisited. It is not a single-file fix; it requires changing measurement frameworks, re-educating stakeholders, and redesigning incentive structures across the organisation.
Closest to 'strong gravitational pull' (b7). The tags (culture, metrics, management) and applies_to (web, cli — broad scope) indicate this affects every engineering team regardless of context. Once a metric becomes a target, every sprint planning, code review, and hiring decision is subtly shaped by it. The burden is persistent and cross-cutting, influencing all work streams, though it stops short of b9 because a team can partially escape it by adopting counterbalancing metrics without a full rewrite.
Closest to 'serious trap — contradicts how a similar concept works elsewhere' (t7). The misconception field states that more metrics are assumed to equal better measurement, when in fact more targets create more gaming surfaces. This is a well-documented but widely ignored trap: competent developers routinely set up coverage gates, velocity dashboards, and DORA metrics in good faith, only to discover the metric has decoupled from the reality it was measuring. It scores t7 rather than t9 because the law is well-known by name, even if rarely applied correctly in practice.
Also Known As
TL;DR
Explanation
Charles Goodhart's observation applies constantly in software engineering: lines of code as a productivity metric incentivises verbose code; code coverage as a quality metric incentivises meaningless tests; story points as velocity incentivises point inflation. The metric was valid as an indicator of the real goal, but once it becomes the target, teams optimise the metric while the real goal deteriorates. The fix: use multiple metrics, change metrics regularly, and focus on outcomes over outputs.
Common Misconception
Why It Matters
Common Mistakes
- 100% code coverage as a quality gate — developers write trivial tests to hit the number without asserting meaningful behaviour.
- Story points as team performance measure — teams inflate estimates to look productive.
- Bug count as quality metric — teams stop filing bugs or close them as 'by design'.
- DORA metrics as performance review criteria — teams game deployment frequency with trivial deploys.
Code Examples
// 100% coverage target — passes coverage, tests nothing meaningful:
public function testAdd(): void {
$calc = new Calculator();
$calc->add(2, 3); // Line executed — counted as covered
$this->assertTrue(true); // No assertion — mutation survives
// Coverage: 100% ✓ Actual quality: 0
}// Focus on the real goal — meaningful assertions:
public function testAdd(): void {
$this->assertSame(5, (new Calculator())->add(2, 3));
$this->assertSame(0, (new Calculator())->add(-1, 1));
$this->assertSame(-3, (new Calculator())->add(-1, -2));
}
// Coverage may be 85% — quality is high
// Measure: mutation score, not line coverage