←back to thread

Estimates are difficult for developers and product owners

(thorsell.io)
225 points todsacerdoti | 4 comments | 07 Dec 25 19:17 UTC | HN request time: 0.001s | source
Show context
yen223 ◴[07 Dec 25 20:01 UTC] No.46184611[source]▶
The unique thing about estimates in software engineering is that if you do it right, projects should be impossible to estimate!

Tasks that are easiest to estimate are tasks that are predictable, and repetitive. If I ask you how long it'll take to add a new database field, and you've added a new database field 100s of times in the past and each time they take 1 day, your estimate for it is going to be very spot-on.

But in the software world, predictable and repetitive tasks are also the kinds of tasks that are most easily automated, which means the time it takes to perform those tasks should asymptotically approach 0.

But if the predictable tasks take 0 time, how long a project takes will be dominated by the novel, unpredictable parts.

That's why software estimates are very hard to do.

replies(19): >>46184700 #>>46184806 #>>46184873 #>>46184947 #>>46185145 #>>46185627 #>>46185768 #>>46185915 #>>46185952 #>>46186292 #>>46186318 #>>46186774 #>>46187054 #>>46187512 #>>46188101 #>>46189271 #>>46189483 #>>46196595 #>>46201725 #
lloeki ◴[07 Dec 25 22:31 UTC] No.46185952[source]▶
From another thought-experiment-y perspective:

Say you have problem A to solve. Then either one of those is true:

1) it has been solved before, ergo by virtue of software having a zero cost of copying (contrary to, say, a nail, a car, or a bridge), so there is no actual problem to be solved.

2) it hasn't been solved before, ergo it is a new problem, and thus at any moment you may turn a stone and discover something that was not foreseen (whether they are rabbits, yaks, bikesheds, dragons, or what have you eldritch horrors) and thus of unknown cost.

Any task that cannot be obviously fit into one or the other can nonetheless be split into an assembly of both.

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.

replies(1): >>46188706 #
1. zffr ◴[08 Dec 25 05:27 UTC] No.46188706[source]▶
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.

replies(3): >>46189848 #>>46190599 #>>46190975 #
2. kragen ◴[08 Dec 25 08:36 UTC] No.46189848[source]▶
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.

3. bonesss ◴[08 Dec 25 10:16 UTC] No.46190599[source]▶
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.

4. Sammi ◴[08 Dec 25 11:13 UTC] No.46190975[source]▶
> 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.