Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software effort estimation is mostly fake research (2021)

shape-of-code.com

Post reply on HN
Print view View original

21–30 of 212 posts

Re: Software effort estimation is mostly fake research (2021)

#21

Post by x86x87 »

quickthrower2 wrote: post #10

My instinct is that if you can put numbers and predictions based on real world estimations, then you are estimating simple things. For example, you can estimate how long it will drive from A to B. Google maps does a brilliant job of this, showing the busy sections. Often I get there +/- a minute from what is estimated over a 60 minute journey. But estimating how long someone will take to do a project, where the proje…

Also, to get better estimates you need to sometimes do some [research] work. Without it ykur guesses are even wilder but with it you have to ack that you've spent time on it, evenif you never get to do the actual work.

Re: Software effort estimation is mostly fake research (2021)

#22

Post by neodypsis »

> Agile techniques are widely used these days, and datasets from the 1990s are not applicable. What datasets do researchers use to build Agile effort estimation models?

In an undergraduate software engineering course I took we learned an effort estimation methodology that assumed a particular way of working (similar to Agile), but also a particular software architecture. The problem was that students then had to adopt such an architecture, even though it wasn't the best fit to the problem at hand, just so that they could complete the effort estimate. Are there methods that are independent of the software architecture?

Re: Software effort estimation is mostly fake research (2021)

#23

Post by danielvaughn »

I feel like the core problem here is one that can never be resolved, because it's the result of two valid but opposing forces.

On one hand you have business stakeholders, who can see the business reality - money doesn't grow on trees and runways are very real and scary, so without deadlines companies fundamentally cannot function.

On the other hand you have engineers, who either explicitly or implicitly understand the other truth - that reliably estimating a project requires knowing all the steps involved, and if you know all the steps involved, then you'd have already automated it.

Re: Software effort estimation is mostly fake research (2021)

#24

Post by vletal »

quickthrower2 wrote: post #10

My instinct is that if you can put numbers and predictions based on real world estimations, then you are estimating simple things. For example, you can estimate how long it will drive from A to B. Google maps does a brilliant job of this, showing the busy sections. Often I get there +/- a minute from what is estimated over a 60 minute journey. But estimating how long someone will take to do a project, where the proje…

> We are building Sydney Opera Houses.

Sorry, this made me laugh. I know there are software engineers which build clean and polished beautiful mega structures. I _aspire_ to that. Yet that is a niche market.

In reality, most devs are making unique family Vilas at best.

I wish I could ever say I feel like I contributed to an equivalent of 'Sydney Opera House'.

Re: Software effort estimation is mostly fake research (2021)

#25

Post by scraptor »

MuffinFlavored wrote: post #20

If your manager says "I need an estimate" and you can't tell your manager "no, that's fake research/not worth my time", does it really matter what is/isn't "fake research"?

Does your manager expect you to obtain your estimate using a machine learning approach from a research paper?

Re: Software effort estimation is mostly fake research (2021)

#26

Post by HankB99 »

quickthrower2 wrote: post #10

My instinct is that if you can put numbers and predictions based on real world estimations, then you are estimating simple things. For example, you can estimate how long it will drive from A to B. Google maps does a brilliant job of this, showing the busy sections. Often I get there +/- a minute from what is estimated over a 60 minute journey. But estimating how long someone will take to do a project, where the proje…

> in software you are always doing something new

Yes, and invariably anything that comes up and wasn't accounted for in the estimate will take more time, not less.

Re: Software effort estimation is mostly fake research (2021)

#27

Post by dustingetz »

danielvaughn wrote: post #23

I feel like the core problem here is one that can never be resolved, because it's the result of two valid but opposing forces. On one hand you have business stakeholders, who can see the business reality - money doesn't grow on trees and runways are very real and scary, so without deadlines companies fundamentally cannot function. On the other hand you have engineers, who either explicitly or implicitly understand th…

as you essentially say, software isn’t solved yet, so the business wins this one for now

Re: Software effort estimation is mostly fake research (2021)

#29

Post by ethbr0 »

x86x87 wrote: post #21
quickthrower2 wrote: post #10

My instinct is that if you can put numbers and predictions based on real world estimations, then you are estimating simple things. For example, you can estimate how long it will drive from A to B. Google maps does a brilliant job of this, showing the busy sections. Often I get there +/- a minute from what is estimated over a 60 minute journey. But estimating how long someone will take to do a project, where the proje…

Also, to get better estimates you need to sometimes do some [research] work. Without it ykur guesses are even wilder but with it you have to ack that you've spent time on it, evenif you never get to do the actual work.

I.e. spiral https://en.m.wikipedia.org/wiki/Spiral_model

Re: Software effort estimation is mostly fake research (2021)

#30

Post by klodolph »

danielvaughn wrote: post #23

I feel like the core problem here is one that can never be resolved, because it's the result of two valid but opposing forces. On one hand you have business stakeholders, who can see the business reality - money doesn't grow on trees and runways are very real and scary, so without deadlines companies fundamentally cannot function. On the other hand you have engineers, who either explicitly or implicitly understand th…

When the problem can never be resolved, you redefine the problem until you find a version of the problem with a good solution. So if the problem is that software is hard to estimate, which is hard, we redefine the problem to something like “I want to be able to ship something people want to buy, before we run out of money” or “I want to ship a game in time for Christmas” or “I want to reduce operating costs so we don’t drown in debt.”

Incidentally, the process of writing a software program is often the same process—redefining the problem until you find a problem with a good software solution, rather than finding a hard problem and throwing software at it until you die from exhaustion.

Post reply on HN