←back to thread

225 points todsacerdoti | 4 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 #
bpt3 ◴[] No.46185145[source]
If software developers want to be then seriously as a profession, they need to be able to provide and justify estimates for their work.

Everything you said could apply to a new bridge, building, pharmaceutical compound, or anything else that is the result of a process with some known and some unknown steps.

replies(3): >>46185320 #>>46185578 #>>46189911 #
1. XorNot ◴[] No.46185320[source]
Pharmaceutical compounds frequently don't make it to market after significant investment.

No one in that industry is giving estimates based on developing brand new drugs - they're giving estimates related to manufacturing lead times, unalterable physics time lines, and typical time to navigate administrative tasks which are well known and generally predictable (but also negotiable: regulations have a human on the other end). All of this after they have a candidate drug in hand.

Same story with bridge building basically: no one puts an estimate on coming up with a brand new bridge design: they're a well understood, scalable engineering constructions which are the mostly gated by your ability to collect the data needed to use them - i.e. a field survey team etc. - and also once again, regulatory processes and accountability.

replies(1): >>46185825 #
2. bpt3 ◴[] No.46185825[source]
Yes, that's my point. There's way more uncertainty in trying to bring a new drug to market or build a new bridge than creating yet another CRUD app, yet somehow they are any able to break these efforts into tasks that can be estimated and tracked and many software engineers think they should be exempt from any accountability to schedule or budget.
replies(1): >>46186655 #
3. Aeolun ◴[] No.46186655[source]
And do you think those things are delivered on schedule any more often than software projects?
replies(1): >>46187228 #
4. bpt3 ◴[] No.46187228{3}[source]
Take a look at the top of this thread and see what we're talking about.

The fact that people in many industries are not good at estimating doesn't mean that it's impossible in software development specifically and uniquely, as was originally claimed.