[marcus_holmes]

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.

[monkeyshelli]

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

[prepend]

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

[marcus_holmes]

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

[CuriousSkeptic]

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

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

[marcus_holmes]

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

[mewmew]

> 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