←back to thread

225 points todsacerdoti | 1 comments | | HN request time: 0s | source
Show context
yen223 ◴[] 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 #
seviu ◴[] No.46184700[source]
I am in a project where we have to give estimates in hours and days.

Needless to say we always underestimate. Or overestimate. Best case we use the underestimated task as buffer for the more complex ones.

And it has been years.

Giving estimations based on complexity would at least give a clear picture.

I honestly don’t know what the PO and TL gains with this absurd obscenity.

replies(3): >>46184742 #>>46184798 #>>46185192 #
SoftTalker ◴[] No.46184798[source]
The last director I had would ask "is it a day, a week, a month, or a year" he understood that's about as granular as it's possible to be.

And he really only used them in comparison to estimates for other tasks, not to set hard deadlines for anything.

replies(3): >>46185262 #>>46185277 #>>46185854 #
XorNot ◴[] No.46185277{3}[source]
Knowing nothing else about him, I like him based on this alone.

I've been in planning sessions where someone would confidently declare something would take half a day, was surprised when I suggested that it would take longer then that since they were basically saying "this'll be finished mid-afternoon today"...and was still working on it like 3 weeks later.

replies(1): >>46185623 #
dgunay ◴[] No.46185623{4}[source]
Besides the usual unknown unknowns, I've also seen this happen with tasks that involve a lot of coordination in the SDLC. Oh the PR went up at at 2pm PST? Coworkers in EST won't review it until tomorrow. Maybe some back and forth = another day until it clears review. Then QA happens. QA is heavily manual and takes a few hours, maybe with some false starts and handholding from engineering. Another day passes. Before you know it the ticket that took an hour of programming has taken a week to reach production.
replies(2): >>46187047 #>>46187069 #
1. jrs235 ◴[] No.46187069{5}[source]
Are we estimating developer cost (investment cost, writing code only tome), development costs (investment costs including QA time), or time to delivery and first use? People want and use estimates for different purposes. You point out great reasons why knowing what the estimates are for is important.