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

181–190 of 212 posts

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

#181

Post by zo1 »

adrianN wrote: post #117
jillesvangurp wrote: post #97

A bad estimate is better than no estimates at all. There are plenty of empirical studies that prove that. Some computer scientists have a hard time dealing with non mathematical proofs. They have a huge blind spot for things like empirical case studies, qualitative studies, etc. Those are tools that people in other fields use when mathematical models fall short. There are not a lot of useful mathematical models you c…

A bad estimate gives you a handle on how easy or hard your engineers think that something is. Experience shows that this has little correlation with how easy or hard something really is.

And I'd argue that their bad estimate includes their knowledge of how difficult the task is. Unless you're completely broken, you're not going to under-estimate something wildly if you are unsure of what you need to do or have no idea how to do it.

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

#182

Post by _ea1k »

eftychis wrote: post #60
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…

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…

This also makes fruitful grounds for scapegoating. 1.5 years into the "6 month" project, they can reorganize because of the catastrophic failure.

Then the new organization can say it wasn't because they misestimated, it was just the poor organizational structure before.

Obviously this new structure would have achieved the result in the time allotted.

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

#183

Post by _ea1k »

thaneross wrote: post #110
frant-hartm wrote: post #93

Earlier quoted context omitted.

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

I hate to say it but from my 20+ years in the industry, this is the norm.

It is more common than not, but it is still best to avoid such places.

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

#184

Post by _ea1k »

nprateem wrote: post #47

My conclusion is there are 2 kinds of engineer: good ones and shit ones. Good ones just need to be told what to do and be left to get on with it. They value autonomy, and any attempt to micromanage them with agile bullshit drastically demotivates them. Shit ones are shit. They need a good one to help them get through their tickets, by asking what's taking so long and showing them better ways of approaching the proble…

I don't agree with the tone, but there's some truth here.

A good SM or delivery lead can make a huge difference. Good management is very impactful too. So we should add as much of that as possible.

That last part is obviously absurdly wrong, but it is easy to see the pathway that gets people there.

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

#185

Post by regularfry »

mcmcmc wrote: post #120
nprateem wrote: post #47

My conclusion is there are 2 kinds of engineer: good ones and shit ones. Good ones just need to be told what to do and be left to get on with it. They value autonomy, and any attempt to micromanage them with agile bullshit drastically demotivates them. Shit ones are shit. They need a good one to help them get through their tickets, by asking what's taking so long and showing them better ways of approaching the proble…

As someone who pulled part-time scrum master duties in a seed stage startup, the problem is that engineers, even good ones, tend to be not-so-great communicators. Having someone to grease the wheels in stand ups and planning meetings decreases the time it takes for issues to surface. The other half of the job is cleaning the backlog and keeping the product owner from derailing development. It’s more about waste reduc…

Not only that. Agile processes in general are supposed to protect everyone from sinking a tonne of effort into successfully building the wrong thing. It doesn't matter if people aren't going as fast as they otherwise might, if the counterfactual has them going in completely the wrong direction.

Scrum itself is more specifically designed to protect the team from management interference. Engineers might think it's a waste of time preventing them from getting things done, but in its absence (where it's truly needed) what would actually be happening is constant micromanagement, context switching, and death-march deadline pressure. In its originally-intended form it's not an arbitrary collection of hand-holding niceties, it's a self-defence measure.

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

#186

Post by regularfry »

danielvaughn wrote: post #107
pyrale wrote: post #69

Earlier quoted context omitted.

> money doesn't grow on trees and runways are very real and scary, so without deadlines companies fundamentally cannot function. That's a non-sequitur. there are plenty of ways to run a project under a budget that don't involve deadlines.

Interesting, though not sure I follow. My reasoning is that the ultimate deadline is the “we run out of money and go out of business” point, from which all other points follow. So a project may be organized differently, but under the hood it’s all the same - get more money before you lose all the money.

This is only a hard deadline if you have to wait until the end of the project before any money happens.

This is the problem with the word "project" and, more generally, with formal project management: it attempts to divide the timeline into "Before Delivery" and "After Delivery" and often it doesn't care what the world looks like other than as a bag of deliverables.

That's not the only way to do it, of course, but it's the mental trap you set for yourself by thinking about things as Projects with a capital P.

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

#187

Post by NovemberWhiskey »

I can give you some kind of reasonable estimate for precisely one kind of work: stuff for which I have good domain knowledge, unfettered access to a small set of stakeholders who are in unambiguous agreement on the need, that is delivered on a technology platform that I know well, using people with whom I've worked in the past, and that has no dependencies on other teams.

This has happened approximately three times in my career.

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

#188

Post by regularfry »

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…

I actually disagree. Well, sort of.

We can almost always say "it can't possibly take less than X". In fact, that X is often what gets given as the estimate, which is... not good, when you think about it.

We can also often say "it is very unlikely to take more than Y". Between X and Y is the range of possible values for a real estimate.

The problem comes when X and Y aren't just far apart, they're orders of magnitude apart. If you go back to your stakeholders with that range, what you should be able to hope for is a reasoned discussion not about how Y is too big (which it almost certainly will be) but on how to reduce the size of the range.

That involves having more information about either the problem or the solution, so you (or they) are either off into more analysis, or you're into solution design. When you have a design in terms of subparts similar to things that have been built before, you've got something that's less Sydney Opera House and more Sydney Opera House LEGO Creator Expert Set 10234.

So yes, at the specific point in time where someone asks you "how long to do this thing that's never been done before" there's almost certainly not enough information to give a response that bears relation to reality, but that should be the start of the conversation, not the end.

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

#189

Post by qprofyeh »

IanCal wrote: post #41
qprofyeh wrote: post #34

Earlier quoted context omitted.

I tend to disagree. Estimate this more complex situation: Integrate vendor B’s API where you don’t have prior experience with vendor B’s product let alone their API, and where our system is built specifically around vendor A’s API and workflow. This requires backend and frontend (customer and admin UI) changes given that everything is tied to vendor A’s API currently.

Have you ever done this before? How long has it taken in the past? What are the key first steps? Investigate the API and product right? How long has that taken when you've done it before? Your first deliverable is a plan of it's that unknown. Now you've investigated you know more about what needs to be done. You can compare it to previous times you've done similar things and estimate how long it should take.

Your basic approach is sound. Problem is the existence of unknown unknowns, those that only appear when you reach a later stage where these unknown unknowns decide to present themselves. Often causing an unknown amount of unknown effort requires from an unknown team member or third party. This invalidates earlier timeframes, and in worst case even the entire strategy.

How does one put a proper estimate on this? Any answer is but a wild guess.

(This is where PMs provide added value by realigning business and product teams around the new situation.)

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

#190

Post by davely »

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…

Hah!

One of the knocks against me in my last performance review was that I had poor time estimation for completing tasks.

I asked my lead for help in getting better at this and they were basically a real life version of the Neil deGrasse Tyson hand waving GIF.

Post reply on HN