The reason a bonus for lines of code produces long code

A software company introduces a productivity bonus tied to lines of code written per week. Within a month, developers are writing more lines. They are also copying functions, splitting single operations into multiple steps and avoiding reusable libraries. The codebase grows. Its quality shrinks. The metric is rising while the thing it was meant to measure is falling.

What everyone sees

Managers see the rising line count and interpret it as increased output. The metric was chosen because it is easy to measure, and because more code feels like more work. The alternative — measuring code quality, maintainability or bug rate — is harder to quantify, so the easy metric fills the governance vacuum. Nobody asks whether the metric and the goal have diverged, because the metric is the only thing being reported.

What is actually happening

Goodhart’s Law states that when a measure becomes a target, it ceases to be a good measure. Campbell’s Law adds that the more a quantitative indicator is used for decision-making, the more it will be subject to corruption pressures and the more apt it will be to distort the process it is intended to monitor. The mechanism is not sabotage; it is rational optimisation against the reward function. Developers writing long code are doing exactly what the incentive tells them to do.

Why it stays hidden

The distortion hides because the metric looks healthy. Dashboards show output rising, and rising output is the story that dashboards are built to tell. The deterioration in code quality is invisible to the metric, so it is invisible to anyone who governs by metric. By the time the consequences appear — more bugs, slower releases, higher maintenance cost — they are attributed to technical debt or team changes, not to the incentive that created them.