←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 #
121789 ◴[] No.46184742[source]
Hours is insane. But ultimately time is money and opportunity cost. Software engineering can’t be the only engineering where you ask the engineers how much something will cost or how much time it will take and the answer is “it’s impossible to know”. Even very inaccurate estimates can be helpful for decision making if they are on the right order of magnitude
replies(4): >>46184821 #>>46184857 #>>46184975 #>>46189784 #
yetihehe ◴[] No.46184821[source]
I think software is one of those VERY rare things, where inaccurate estimates can actually be inaccurate by "orders of magnitude". After 20 years in the field, I still managed to use 2 months of time on a task that I estimated as 10 days.
replies(3): >>46185004 #>>46185166 #>>46185206 #
camel_gopher ◴[] No.46185004{4}[source]
A rule that has suited me well is to take an estimate, double it, and increase by an order of magnitude for inexperienced developers. So a task the say would take two weeks ends up being 4 months. For experienced developers, halve the estimate and increase by an order of magnitude. So your 10 days estimate would be 5 weeks.
replies(3): >>46185073 #>>46185167 #>>46185235 #
1. QuercusMax ◴[] No.46185167{5}[source]
The biggest estimation effort I ever took part in was a whole-system rewrite[1] where we had a very detailed functional test plan describing everything the system should do. The other lead and I went down the list, estimated how long everything would take to re-implement, and came up with an estimate of 2 people, 9 months.

We knew that couldn't possibly be right, so we doubled the estimate and tripled the team, and ended up with 6 people for 18 months - which ended up being almost exactly right.

[1]: We were moving from a dead/dying framework and language onto a modern language and well-supported platform; I think we started out with about 1MLOC on the old system and ended up with about 700K on the rewrite.