←back to thread

Estimates are difficult for developers and product owners

(thorsell.io)
225 points todsacerdoti | 5 comments | 07 Dec 25 19:17 UTC | HN request time: 1.184s | 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 #
wpietri ◴[07 Dec 25 20:41 UTC] No.46184947[source]▶
And I'd add that the need for them is a sign they aren't worth doing.

As you say, worthwhile software is usually novel. And to justify our expense, it needs to be valuable. So to decide whether a project is worth doing, we're looking at some sort of estimate of return on investment.

That estimate will also, at least implicitly, have a range. That range is determined by both the I and the R. If you don't have a precise estimate of return, making your estimate of investment more precise doesn't help anything. And I've never seen an estimate of return both precise and accurate; business is even less certain than software.

In my opinion, effort put into careful estimates is almost always better put into early, iterative delivery and product management that maximizes the information gained. Shipping early and often buys much clearer information on both I and R than you can ever get in a conference room.

Of course all of this only matters if running an effective business is more important than managerial soap opera and office politics. Those often require estimates in much the same way they're required from Star Trek's engineers: so the people with main character syndrome have something to dramatically ignore or override to prove their dominance over the NPCs and material reality.

replies(4): >>46185137 #>>46185239 #>>46185289 #>>46188898 #
bpt3 ◴[07 Dec 25 21:04 UTC] No.46185137[source]▶
The solution you described is basically agile, and that definitely includes estimates and deadlines.
replies(4): >>46185372 #>>46185512 #>>46186209 #>>46186224 #
Mtinie ◴[07 Dec 25 21:32 UTC] No.46185372[source]▶
It’s Agile philosophically, and how it should be.

But that is rarely how it works. In the dozens of different projects across ten or twelve companies I’ve had insight into, “doing Agile” is analogous with “we have a scrum master, hold stand ups, and schedule iterations” while the simple reality is “Agilefall.”

replies(1): >>46185417 #
bpt3 ◴[07 Dec 25 21:37 UTC] No.46185417[source]▶
Agreed, but the parent poster said that estimates shouldn't be done at all, which is not a legitimate argument to make in any scenario.
replies(2): >>46185840 #>>46186243 #
collingreen ◴[07 Dec 25 22:20 UTC] No.46185840[source]▶
I, and others, don't agree with the blanket statement that "no estimates" is not a legitimate argument in any scenario. Can you expand on why you think there isn't a single case where estimates don't add value? Similarly, is there anything specifically in that post's claims that you think was incorrect, leading to their false conclusion?
replies(1): >>46187148 #
1. bpt3 ◴[08 Dec 25 01:01 UTC] No.46187148[source]▶
Okay, a scenario where you're building a hobby project alone and you don't care if or when it gets finished would be one where estimates aren't needed.

There is no scenario where it's appropriate or necessary when developing software professionally or even as a side project where others are expecting you to complete work at some point.

One of the many misconceptions in the original comment in this thread is that "worthwhile software is usually novel", which is not the case without a very specific and novel definition of worthwhile that I don't believe was intended.

replies(1): >>46189686 #
2. kragen ◴[08 Dec 25 08:14 UTC] No.46189686[source]▶
If software isn't novel, that means some other, existing software does the same thing just as well in the same way on the same platform. So, unless it's a hobby project you're building alone, why don't you just use the existing software?

I think that writing software that isn't novel fails to be worthwhile by a perfectly ordinary, mainstream definition of "worthwhile".

replies(1): >>46191845 #
3. bpt3 ◴[08 Dec 25 13:15 UTC] No.46191845[source]▶
So you would consider a CRUD app with some basic business rules to be novel? Basically meaning that any software that requires any development effort is novel?

That's a completely valid definition of worthwhile software, but to claim it's impossible to create an estimate to complete said development is absurd.

replies(1): >>46194756 #
4. collingreen ◴[08 Dec 25 17:04 UTC] No.46194756{3}[source]▶
You just keep saying things are absurd or obvious but not putting anything behind it.

I hope this isn't a semantics game where things like "1 - 6 months" counts as an estimate in this context.

The point way back up this thread was accurate timelines for complicated, novel work have large error bars but those error bars aren't as bad as the equivalent error bars on estimating whatever "return" it is being pitted against.

replies(1): >>46196494 #
5. bpt3 ◴[08 Dec 25 19:26 UTC] No.46196494{4}[source]▶
I wouldn't consider something like "1-6 months" as a valid estimate, as that would indicate there is too much uncertainty and it needs to be broken down into subtasks that can be estimated with much less variance.

I've written what is probably several pages now in response to two individuals who are redefining terms in order to play the exact semantic games you mentioned, but in order to claim no estimation of any sort needs to be done. We seem to be done talking past each other now that I explicitly pointed out their usage of non-standard terms and my suspicions of why (having also unfortunately lived through software development managed by Gantt chart and other unpleasant experiences where someone who had no idea what they were managing was in control of a project), which is fine with me.

Feel free to describe your experience in practice when working in an organization where software developers answer to no one but themselves and are never asked for any justification for their progress or any projections of when they will be finished (both of which would require estimation to provide).

If you are able to tell stakeholders something like you'll be done in 1-6 months or provide no insight at all into when your tasking will be done, do no tracking of progress internally, and perform no collaboration around the completion of synchronous tasks within your team, I'll acknowledge no estimation is taking place during that process.