Comment by 495636483 | Hacker News Reader

Comment by 495636483 | Hacker News Reader

Parent Full thread

https://en.m.wikipedia.org/wiki/Goodhart%27s_law

https://en.m.wikipedia.org/wiki/Campbell%27s_law

If you know a thing or two about evolution, it should be obvious how these shortcuts will play out.

And still, you hear about similar metrics being used all the time... All over the place.

I suspect, in most cases, it's actually bad metrics stacked and really the manager trying to putting a metric on their own "contribution". (Parasitic isn't even the word, but rather viral or prionic...)

In the end, truly and reproducibly recognizing individual contribution is probably beyond human comprehension for any non-trivial tasks. Maybe your product actually benefits a lot from that one guy, who is just very good at promoting a good spirit, being fun to work with, rather than being the most proliferative coder. And how do you measure how hard a problem is? Does is matter who perceives it as hard in your team?

I think, it's one of those things, where trying to be clever will most likely make things much worse because the manual labor and personal involvement of the past actually was already best fitted for the task, by utilizing the human brain where it excels. Humans doing human things with humans, without being willfully ignorant about the complexity at hand.

It's always fun trying to explain to non-tech management the two truths of managing software development:

1. There is no objective measure of productivity that can be applied to software development.

2. Accurate estimation of development times is impossible (not difficult, actually theoretically impossible). All estimates of development times are wrong, some by more than an order of magnitude.

The second one is especially hard to grok for non-techies. I have to explain that if you insist on accurate estimates, you will get grossly padded estimates [0]. And the work will expand to fit the time available (sometimes resulting in the task exceeding even the massively padded estimates because the work expanded with the estimate). I've had many entertaining conversations attempting to explain this.

[0] Because every developer knows that an estimate will magically become a deadline.

> 2. Accurate estimation of development times is impossible (not difficult, actually theoretically impossible). All estimates of development times are wrong, some by more than an order of magnitude.

Some are useful. The goal isn’t to be right in that there’s no award for perfect estimates, that would be stupid. But having an estimate, especially with relevance to multiple features is helpful.

At one time a team I worked on used “story point cards” and each person would estimate blindly and the discuss. It was interesting hearing people’s reasons behind their magnitudes.

Over time the story estimates got pretty good. But the number was completely useless objectively and made no sense when comparing teams or different projects.

Yeah, there are methods of getting to a useful "it's about this big" estimate.

The real pain is turning estimates into deadlines. "About this big" doesn't equate to "it'll be finished on Thursday".

It should not be express as size then. It should be expressed in dice!

“This story is 4D6, that one about a D20”

haha, love it. "Difficulty estimate: 15. Roll a d20 every day to see if it's completed, with a +1 modifier per day"

> The second one is especially hard to grok for non-techies. I have to explain that if you insist on accurate estimates, you will get grossly padded estimates [0]. And the work will expand to fit the time available (sometimes resulting in the task exceeding even the massively padded estimates because the work expanded with the estimate). I've had many entertaining conversations attempting to explain this.

Sounds like Hofstadter's law.

"Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law."

[1]: https://en.wikipedia.org/wiki/Hofstadter%27s_law

> 2. Accurate estimation of development times is impossible (not difficult, actually theoretically impossible). All estimates of development times are wrong, some by more than an order of magnitude.

Personally now-a-days I care more about velocity. If the team can deliver the smallest value added to the system within a week, we are good. The more constant velocity the team has, the more Management trusts you to produce value and get their things done without the need to have massive estimation parties that almost always end up being wrong.

The sad thing is, once the velocity gets bogged up or waving (Org change, contantly changing directions,..) the estimation parties are here to stay and it's quite hard to get back to where the team was.

Now think about money as a metric for human prosperity. Which creatures really roam the markets and where is mankind's place there? Is any dynamic stability of intrinsic value to us? (Not trying to be edgy, or deep, I just think those are the questions indeed usually not answered by free market enthusiasts.)

Reply on news.ycombinator.com