> Over-measurement is often worse than not measuring anything at all.Yes. Not only is "time spent" or "code written" or "features implemented" or even "user engagement" a lossy metric in the best of cases but it can literally end up doing the exact opposite of what you intended. Campbell's & Goodhart's laws are often cited. The trap I see in software companies is a hyperfocus on quantifiable short term wins, entirely glossing over the value created by longer term cultivation of quality. One can see projects where code cleanliness, documentation, testing, CI, and performance have been effectively disincentivised, even though, in the short, mid, and long-term, you will see gains. Such gains, however, are less visible and less quantifiable to the kinds of people who define and foster the metric regimes.
A narrative I observe variations of:
Universe X:
- Programmer A implements feature in one week. They get a admiration and a raise.
- One year later: Programmer B implements feature in 3 weeks, because they had to use Programmer A's shoddy and inconsistent API.
Universe Y:
- Programmer A implements feature in two weeks. Less admiration and no raise.
- One year later: Programmer B implements feature in 1 week, because they were able to use Programmer A's better implemented interface.
Hopefully it's obvious which universe is preferable and produced a net-win. ...
Bad metric regimes are unforuntately not _obviously_ bad when you're inside their machinations. They really need to be dug into to see the fallacies.
One has to look no further than Meta/Facebook for the absolute deteriment caused by overzealous performance reviews and a fixation of experimental upticks in user engagement. It is a bad metric regime.