[mjn]

IBM was big into quantitative code metrics in the '60s through '80s, but the practice ended up developing a bad reputation, since the metrics inevitably created perverse incentives to game the metrics themselves, and sometimes got in the way of doing the right thing if it didn't fit the rigid model's idea of the right thing.

This is basically a version of Campbell's law, from a 1976 paper by Donald T. Campbell: "The more any quantitative social indicator (or even some qualitative indicator) is used for social decision-making, the more subject it will be to corruption pressures and the more apt it will be to distort and corrupt the social processes it is intended to monitor."

Lines of code per unit time (LOC) is probably the most notorious, but there have been dozens of attempted improvements. Function point metrics were a late-'70s approach (also out of IBM) that tried to fix some of LOC's shortcomings as productivity metric, but turned out to be highly correlated to LOC and also problematic. There are dozens of books from the past 50 years with titles like "Applied Software Measurement" and "Measuring the Software Process", but they've become associated with bureaucratic bigcorp software engineering.

[wisty]

Or the "cobra problem". The British put a bounty on cobras in India (to reduce snake-bites). So the snake-catchers bred cobras (some of which escaped, making the problem worse).

Incentives are powerful things.