←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 #
1. Scarblac ◴[] No.46185192[source]
> I honestly don’t know what the PO and TL gains with this absurd obscenity

There are marketing campaigns that need to be set up, users informed, manuals written. Sales people want to sell the new feature. People thinking about road maps need to know how many new features to can fit in a quarter.

Development isn't the only thing that exists.