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

141–150 of 212 posts

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

#141

Post by dekleinewolf »

frant-hartm wrote: post #93
constantcrying wrote: post #72

Earlier quoted context omitted.

Your first mistake was misunderstanding the relationship with management. Time estimations are bargaining, you ask for something and then get a counter offer from management, they don't care that the counter offer from them is delusional. The bargaining is the point, the less time you bargain for the more stressful the development can become. Don't estimate what it should take, estimate what it could take and bargain…

Get out of the company if it has this kind of management.

I'm a manager and when I ask my engineers for an estimate, I always, always increase it for my own purposes.

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

#142

Post by kleene_op »

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…

> multiplied by the amount of people with mechanical keyboards

With negative weights for keyboards with cherry mx blue.

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

#143

Post by peter-mueller »

I've started to use the Log-Normal distribution for estimation. Because I think of development like planning a travel time, the train will either arrive in time or the will be a random amount of interruptions/errors that add up. But there won't be as much stuff that speeds the train up (wins back some time).

Then I try to communicate the distribution in words or show it, which most often has a hard time to be accepted, because managers expect a normal distribution mean.

I let several people estimate large scale features and keep their variance to feed it into the log normal. Often I use a reference project, let the use smaller numbers (but not Fibonacci numbers [1]) to estimate and calculate it back to work days.

[1] I personally think the Planning Poker numbers are a lay man's way to force a Log-Normal distribution in the estimation

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

#144

Post by OJFord »

Farox wrote: post #67
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…

Many, many moons ago I asked my mentor how to estimate. He told me that you should figure out what it feels like, then double it and then take it to the next higher time unit. "hmm, adding that button probably takes about an hour"... 2 days is about right. Almost 30 years later I still find this to be true. Truer than I like.

> Almost 30 years later I still find this to be true. Truer than I like.

This happened 15 months ago?

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

#145

Post by catchnear4321 »

cardy31 wrote: post #50
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…

In this vein, my manager doesn’t appreciate when they ask for an estimate and I say “If I knew how to accurately estimate software projects I would be making millions as a consultant. But I don’t so I’m here”

likely because of your assumption that high paid consultants make accurate estimates.

they do get paid more.

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

#146

Post by offices »

mjburgess wrote: post #134

The best estimate for how long it will take to build X, is to build X many times -- under randomised control conditions -- and take an average. Anything short of this isn't amenable to the scientific method.

Lots of life depends on information discovered without the scientific method.

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

#147

Post by cardy31 »

catchnear4321 wrote: post #145
cardy31 wrote: post #50

Earlier quoted context omitted.

In this vein, my manager doesn’t appreciate when they ask for an estimate and I say “If I knew how to accurately estimate software projects I would be making millions as a consultant. But I don’t so I’m here”

likely because of your assumption that high paid consultants make accurate estimates. they do get paid more.

No my assumption isn’t that consultants make good estimates. It is that nobody in our entire industry knows how to accurately estimate how long a software project will take, so I would be a highly sought-after rare commodity in our industry.

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

#148

Post by ethbr0 »

quickthrower2 wrote: post #86
ethbr0 wrote: post #29

Earlier quoted context omitted.

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 :-)

As with many development methodologies, it probably has a formal version that I'm not understanding.

But in my head, it's always been (1) identify areas of risk, (2) sprint to a prototype that decreases or quantifies that risk, (3) evaluate whether you've reduced risk sufficiently, then either (4a) proceed to the next risk or (4b) do another prototype sprint on this risk, and finally after all pockets of risk have been reduced (5) begin building your finished product.

Believe it comes from state of the art development for military procurement, where "What is even possible?" is a valid question.

But it always resonated with software planning for me, by making it more about risk reduction rather than guessing.

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

#150

Post by rswail »

There are two accurate forms of software development effort estimation:

1. Guess, double it, and raise it to the next time unit.

Example: a 1 day task will take 2 weeks

2. The management inspired "What's the earliest date you can't prove you won't be finished by" system of end date scheduling.

Post reply on HN