Item — HN Reader

> 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.

3 comments

You never want to built anything shoddily, but there is a lot of value in doing minimum scope. Testing, clean code, etc shouldn't be negotiable in most shops, but scope can be really trimmed down in a lot of scenarios.

Universe Z: - Programmer X implements feature A in 1 week with tiny scope - Feature B is mothballed and never gets built

Universe A: - Programmer X implements feature in 2 weeks - One year later: This functionality is broken apart into a well defined microservice with additional responsibilities. This needs a total rewrite as a v2 API.

Universe B: - Programmer implements a feature in 1 week - One month later with that extra week they were able to squeeze in an unrelated enhancement to the system that delivered .5% extra revenue during Black Friday.

I find most of the productivity metrics fail because you're squeezing the wrong end of the process. You want to spend the most time making sure you're doing what matters and has value, and then it will almost always be worth the time. This makes people feel engaged, which will lead to a lot more productivity than when you're pushing them to build something they don't care about.

If you really wanted to get into waste, how about the building to spec process?

Spec universe: engineer makes thing. bean counters believe they will be out of business if others see how thing is made and copywright their code. another engineer wants to make the same thing. a second engineer has to be brought in to write up a spec. the other engineer now tries to reinvent this wheel from basically a telephone game description on how it should work and behave. as a result any time an engineer needs a wheel you need a second engineer to describe it to you so you can reinvent the wheel.

open source universe: engineer makes thing. second engineer forks thing.

The universe X example has some merit too. The developer got a raise, the business was excited enough to get this feature done ahead of schedule that someone actually put in the effort to push through a raise, and the total cost for this was one man-week of extra work a year later - basically a drop in the bucket, budget-wise.

You're focusing too much on the specifics of the hypothetical rather than the point of the hypothetical. If you can't get out to the abstraction, then in universe X, programmer B-Z all spend 3 weeks on a feature, and in universe Y, programmer B-Z all spend 1 week on a feature. So we've got an extra man year being burned, all to save a man week upfront. Extend to whatever point short of breaking the analogy you care to.

Universe Y is fine if the company is certain to survive for one year but it is quite possible that slow development of features will mean that in Universe Y there is no Programmer B to benefit from the beautiful API.