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

81–90 of 212 posts

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

#81

Post by keyle »

nsoonhui wrote: post #79
keyle wrote: post #37

It's not fake research. It's actually quite an established science in the 24 years I've been doing it. Take your first guess, double it, double it again if the stakeholder is a poser, add 20% per developer less experience than you, subtract 10% for the features you're going to essentially copy paste, add 15% for sick leave (browsing HN) and then double it for every question you have that are unresolved and divide it…

I can't tell you are serious or satire. If you are serious that kind of estimate is as good as useless because the projects most likely won't be profitable. Can you imagine what will a property developer think if he is informed that his project is going to take at least twice as long to complete?

It was a satire. My go to formula is actually

    (A * B) / C + 2^D + (rand(4, -4) * E) / (0.5 * F)
[A] Time if I did it all by myself

[B] I have no idea what I'm doing ratio

[C] I totally have done this before

[D] Amount of weekly WTF per code review

[E] That stakeholder couldn't hold a stake

[F] Likely hood of it changing by next week

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

#82

Post by quickthrower2 »

HankB99 wrote: post #26
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.

Yes but only in waterfall do you need to accept that issue. In small “a” agile you can now go back to the business and suggest alternatives. (The Opera House was not built exactly to the original plans, for example). Of course that doesn’t work if you need to follow OKR dogma etc. and stick to the original plan.

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

#83

Post by themerone »

I spent 6 months on a feature that I thought would require 2 lines of code and less than an hour to test and ship.

It took 1 month dissecting spaghetti to conclude the task was impossible without a hughe rewrite.

5 months later, the feature was a 2 line change, that could be tested and shipped in an hour.

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

#84

Post by quickthrower2 »

deadfoxygrandpa wrote: post #48
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…

everyone works on stuff that's more complicated than it looks from the outside, and many other fields are able to estimate the amount of work it takes to do something. why cant software? example: in 2006 china formalized plans to build a totally new high speed train system that spans the entire country by 2020, a totally new level of scale that had never been done before. and the plan worked out even a bit ahead of s…

A falacy here is there are commercial just-crud apps. There are not. If it is just crud then just rails scaffold it, and estimate day 1 day.

We could be better and more like the subset of real infrastructure projects that are on time and budget. There is probably a subset of software that is too. You need to a great waterfall. Probably allow prototypes that can be thrown away and have a decent budget for the design phase that will shore up the design and therefore the estimate. And have developers on one project.

Hire project managers that are on their 15th ERP build and making a similar one for you. And use last decades tech so there are less uncertainties (probably not a bad idea for many things - gimme that winforms app without all the slower SPA spinners!)

Even with all this what software lacks is classic Engineering (long degree, good concepts taught, respectable education over leetcode practice and so on). Problem is California will piss all over your business with move fast attitude unless you are boring enough to be off their radar.

Be boring!

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

#85

Post by robjan »

ghotli wrote: post #61

At least when I was younger I was so perplexed by the kind of co-workers that have apparently chosen the profession of working with estimates from other people but continually work without a "confidence level" associated with each estimate. ("two weeks") means such a different thing in reality from ("two weeks", "confidence of 50%"). It's a tuple, it's always been a tuple, it's just downright silly to accept an estim…

In this case why not just divide the estimate by the confidence to get the "true estimate" e.g in your example it's actually a 4 week. If you provide a tuple the confidence will eventually be conveniently dropped in some slide deck then the "2 weeks" will be socialised as the commitment.

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

#86

Post by quickthrower2 »

ethbr0 wrote: post #29
x86x87 wrote: post #21

Earlier quoted context omitted.

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

That is interesting. Going to look more into this. When something looks like common sense codified, then I like it :-)

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

#87

Post by goto11 »

hinkley wrote: post #68
eftychis wrote: post #60

Earlier quoted context omitted.

The real problem is not with estimation but with the management denial. I was asked to estimate a project I owned as a “green” lad. I offered 6 months with a real detailed plan and up to a year with some extras. Based on past rates we had etc. I even did some statistical modeling. They disagreed. They decided to alter the approach, that the principal engineer had suggested and “it would take 2-3 months.” Two years la…

The tell is that as soon as they don’t like how things are going they flip from calling them estimates to commitments. Also if someone’s estimates aren’t perfect, that’s something you can use to justify withholding salary. The game is fixed. It’s just a good deal less fixed for us than for the average person.

Withholding salary? How is that legal?

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

#88

Post by pcblues »

I got better at software project estimation the longer I spent in the dev industry. But I still knew I was using back-of-brain knowledge and probably wouldn't benefit from bringing too much of it into my consciousness. I think it's like kicking a goal from a free kick in soccer. Conscious deliberation seems to be a distraction at best.

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

#90

Post by beezlewax »

ghotli wrote: post #61

At least when I was younger I was so perplexed by the kind of co-workers that have apparently chosen the profession of working with estimates from other people but continually work without a "confidence level" associated with each estimate. ("two weeks") means such a different thing in reality from ("two weeks", "confidence of 50%"). It's a tuple, it's always been a tuple, it's just downright silly to accept an estim…

It doesn't get better with magic values like confidence levels either
Post reply on HN