[zffr]

I was with you until this part:

> Thus any attempt at estimates is as futile as gambling to win, tasks are only ever done when they're done, and "successful estimators" are kings of retconning.

> It's all make-believe.

Software estimates are not futile or make believe. They are useful even if they are not always precise. That’s why the industry continues to use them.

[kragen]

This argument proves too much:

"Bloodletting is not futile or make believe. It is useful even if the patient does not always survive. That's why physicians continue to use it."

"Trial by ordeal is not futile or make believe. It is useful even if sometimes Inquisitors reach mistaken conclusions. That's why Inquisitors continue to use it."

"Lottery-number-picking systems are not futile or make believe. They are useful even if some players never win. That's why players continue to use them."

It is a fully general argument which, if correct, would demonstrate that no practice that had continued for a period of time could ever be ineffective or counterproductive.

[bonesss]

The amount of tap dancing and philosophizing some developers are willing to do to dodge estimates is hilarious.

It’s a skill… a basic part and critical part of engineering. IME the common thread between objectors is that they haven’t made a consistent effort to improve — developing, iterating, and refining their estimation process over time.

Yeah, every line of code is a unique snowflake piece of undefinable research the universe has never seen, equally unknowable and inscrutably enigmatic. But the workers at EngiCorp building EngiCorp products using EngiCorp project routines and resources first, second, and third quarter of 2025 are literal world experts at EngiCorp outcomes. They very reasonably should be able to estimate EngiCorp work in Q4, and account for EngiCorp realities, providing maps of future costs that can drive EngiCorp process improvement and investment.

If I ask for a decking estimate and get back sophistry and smug incompetence, I’m not talking with a super skilled professional deck builder. Doesn’t matter how they hammer, saw, or draw.

[shiroiuma]

In my experience, they have negative usefulness in general.

I did work at one company that used an Agile/Scrum process, and though we didn't estimate actual time, we did estimate effort to complete tasks. That worked pretty well: we had an idea which tasks would be easy and which would be hard, and used that in sprint planning to more effectively use developer time.

But the key is no one was held to an estimate, since it was only that: an estimate. If something took 2x as long as predicted, oh well: we just adjusted our planning and worked around it, delaying other tasks for instance.

The problem I see is when managers demand an estimate, and then turn the estimate into a deadline and try to hold developers to that estimate no matter what.

[Sammi]

> Software estimates are not futile or make believe. They are useful even if they are not always precise. That’s why the industry continues to use them.

The industry continues to fail when trying to use them. They have negative usefulness.