Luu catalogs distributions across sports, medicine, education, and policing that all show the same pattern: sharp spikes just before a human-set cutoff and cliffs immediately after. He argues this is never a natural phenomenon — wherever someone draws a line, agents on the ground reshape behavior to land on the favorable side of it.
By surfacing Luu's essay to 224 points, the submitter elevates the thesis that visible discontinuities in data are diagnostic evidence of human gaming around thresholds. The submission frames the piece as essential reading for anyone designing metrics.
The editorial extends Luu's framework directly to software engineering, arguing that any team graded on a number — P99 latency being the canonical example — will see work deform to meet the threshold rather than improve the underlying system. The lesson is that observed clustering near an SLO boundary is a warning sign of measurement gaming, not engineering success.
Dan Luu's long-running essay Suspicious Discontinuities resurfaced on Hacker News this week, climbing to 224 points. The piece is a catalog of distributions that, on visual inspection, do something they have no business doing: they bunch hard against a human-set threshold, then collapse on the other side. Wherever a human draws a line, the distribution warps around it — not gradually, but with a visible cliff.
The examples are uncomfortable. Marathon finishing times pile up in the few seconds before 3:00, 3:30, and 4:00 and thin out immediately after. Major League batting averages cluster just above .300 because plate appearances get managed at the end of the season. New York cardiac surgeons' reported mortality rates bunch just under the threshold that triggers regulator scrutiny — partly because high-risk patients stop getting operated on. Police-reported use-of-force injuries cluster just below the level that mandates paperwork. School grades pile up at the lowest passing mark. Standardized test scores show vertical walls at cutoffs that trigger interventions or graduation.
Luu's method is deliberately boring. He pulls histograms, points at the spike, and asks the only honest question: why would nature produce a wall there? It almost never does. The wall is always built by someone responding to the threshold — a runner sprinting the last 100 meters, a manager benching a .299 hitter, a surgeon refusing a borderline case, a teacher rounding a 69 to a 70.
The essay is framed in terms of sports, medicine, and education, but the mechanism is the daily reality of every engineering org that measures itself. Pick any number your team is graded on, and the distribution of work will deform until that number looks acceptable, regardless of whether the underlying system improved.
The canonical case is the P99 latency SLO. Set 200ms as the line and you will see a remarkable number of requests landing at 195–199ms — not because the system genuinely tightened, but because somebody added a hedged request, a deadline-aware retry, or a circuit breaker that fails fast at 198ms and returns a degraded response that still counts as success. The histogram looks great. The user experience is worse, because what used to be a slow page is now a fast error. This is Goodhart's Law with a stack trace, and Luu's essay is the cleanest empirical demonstration of it outside the economics literature.
Code coverage thresholds produce the same artifact. A team forced to hit 80% will write tests that exercise lines without asserting on behavior — `expect(fn()).not.toThrow()` as a coverage farm. The coverage report shows a smooth march from 79.4% to 80.1% across a quarter, which is exactly the shape Luu would circle in red. Real test quality almost never moves in a clean step like that.
Performance review distributions are the most visible case inside any company that does stack ranking. The supposedly normal curve always has a suspicious dent right above the PIP threshold and a corresponding bulge just above it, because no manager wants to fire someone borderline and no manager wants to advocate for a 3.6 when 3.7 unlocks a bonus band. The HR dashboards rarely show this, because the buckets are wide enough to hide it, but anyone who has sat in a calibration meeting has watched the sausage get made.
The Hacker News thread surfaces variants engineers know in their bones: bug counts that collapse the week before a release because tickets get reclassified as "works as intended," sprint velocity that tracks the team's read on what management wants to see, on-call page volume that drops the quarter after it becomes a comp factor (because alerts get retuned, not because the system got more reliable), and the eternal mystery of why a service's error budget always lands at 95% consumed.
The practical lesson is not "don't set thresholds" — you have to. The lesson is to instrument the area around every threshold you care about, and treat a cliff in the distribution as a bug report on the metric itself.
Three concrete moves:
Plot the histogram, not the headline number. If your SLO dashboard shows a single P99 figure, you are watching the gamed output, not the system. Show the full latency distribution with the SLO line overlaid. A healthy system has a smooth right tail that happens to fall mostly below the line. A gamed system has a wall at the line. Same summary statistic, completely different reality.
Pair every threshold with a counter-metric that's hard to game in the same direction. Coverage paired with mutation testing score. P99 latency paired with error rate and request-completion semantics (did the response actually contain the data, or a fallback?). On-call pages paired with customer-reported incidents. The point is not to add ceremony — it's to make the cheapest way to move the headline number also move the counter-metric in a bad direction, so gaming costs something.
Audit your own calibration meetings. If your perf review distribution doesn't have a Luu-shaped cliff at the promotion or PIP threshold, you are either unusually disciplined or not looking. Pull the last four cycles of ratings, bin them finely, and ask why the boundaries look the way they do. The answer is almost always more revealing than the ratings themselves.
There's a deeper organizational point too. Discontinuities are a leading indicator of metric capture, and metric capture is a leading indicator of a team that has stopped trying to improve the underlying system and started trying to improve the report. Catching the cliff while it's still small is much cheaper than discovering, two years in, that the entire incentive system has been quietly optimizing against your goals.
The essay isn't new — Luu has been adding to it for years — but its return to the front page lands at a moment when every engineering org is being asked to quantify itself harder: AI-assisted productivity metrics, DORA scorecards, vendor-tracked developer experience indices. Each one is a fresh threshold waiting to be gamed, and each one will generate its own histogram with its own wall. The teams that come out of this era with intact judgment will be the ones that learned to look at the shape of their data, not just the summary statistic at the top of the dashboard.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.