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

Software effort estimation is mostly fake research

shape-of-code.coding-guidelines.com

Post reply on HN
Print view View original

281–290 of 318 posts

Re: Software effort estimation is mostly fake research

#281

Post by parentheses »

didibus wrote: post #82

The issue with estimates are expectations. While nobody acknowledges it, you're not actually asked for an estimate, you're being asked for a quote. The difference is when you're asked for a quote, you're asked how much you will be charging, with the expectations that you'll be willing to eat into your own margins to give a lower quote. That's why it's a negotiation, where you negotiate how much extra effort, time and…

Agreed that often times estimates are mistaken for quotes. Aside from that, my personal experience has been that those who work adjacent to software understands that there’s an element of uncertainty. If those that we work with don’t, it is on us to educate. Improving estimation will eventually improve quality of life for all involved.

Re: Software effort estimation is mostly fake research

#282

Post by imtringued »

ethbr0 wrote: post #227
TeMPOraL wrote: post #178

Earlier quoted context omitted.

Also because planning gets you to make your desires explicit and to put them in a useful framework. Unexpected problems, disruptive as they may be, don't usually derail the whole plan. Some parts may need to be rethought, but others are still valid, and the whole thing keeps you focused.

There was a submission on this (in the annals of HN) where someone made the point that, more often than not and under normal project scenarios, unexpected problems usually do derail the entire software engineering plan. The gist being: estimates are given with zero as a lower bound, and some upper bound. In reality, there is no upper bound. Software engineering can and does involve unexpected problems that would take…

The fundamental problem with estimates is that the recipient believes that the estimate will always turn out to be true, which is obviously not correct.

So, why can't we express the upper bound in combination with uncertainty?

Example: "There is a 50% chance that the feature will be delivered within 1 month."

As time progresses confidence starts increasing and we get closer and closer to how much time it actually takes (be that 5 days, 5 months or 5 years). On the day the feature is completed, confidence is 100% because the real delivery date has become known.

Re: Software effort estimation is mostly fake research

#283

Post by parentheses »

The first key mistake of software estimation in industry is that we rarely talk about confidence (e.g “I’m 50% confident it’ll be shipped in 5 hours, but 99% confident it’ll ship before end of week”). The fact that this is not part of planning means it’s often not part of the conversation and that we seldom think about estimation as a tuple of value and confidence.

The second key mistake is forgetting that estimates (at least in software) are an upper bound. So high estimates are often “better”.

Re: Software effort estimation is mostly fake research

#284

Post by sumtechguy »

tikhonj wrote: post #174
lixtra wrote: post #143

Earlier quoted context omitted.

Typically there are many dimensions to a solution, the negotiation can be about trading one dimension for another. - does it have to be instant or can we run it as a batch - maybe it’s enough to have this tool in English only Etc.

Negotiating scope is a different mindset than negotiating estimates . Even better would be making sure the team understands both the real goal they're trying to achieve and how time plays into it, letting the team make scope trade-offs like that as they go along.

You can tell when they are negotiating time instead of scope. It will be something like "surely we can do this in 2 days not 5?" Instead of "we probably will take 2-5 days to do this but need it in 2 so something of 3 days needs to come out somewhere else". The first one is saying 'work harder and just do it.' The second is 'ok it may take 2-5 days but lets pull something else out to make up for the deadline we want'.

I found orgs that negotiate time did not talk to their team in the first place. Then went on to promise something on behalf of the team. Now they do not want to eat the humble pie of 'I ran the numbers and you only get half' instead they get it going and just overbudget on the thing. Which just makes everyone in the process mad.

Re: Software effort estimation is mostly fake research

#285

Post by parentheses »

BowBun wrote: post #100

It's unfortunate that this HN thread has been reduced to the generic discussion about software estimates when the article is specifically talking about research done on the topic of software estimates. According to the article, proper research remains a struggle due to outdated datasets from before modern agile methodologies, and that the modern datasets from industry are hard if not impossible to gather. If industry…

The issue here is that if you examine most projects today, it requires effort to collect data about what happened. So much that happens is untracked. That untracked stuff is a source of error.

Re: Software effort estimation is mostly fake research

#286

Post by xpe »

SKILNER wrote: post #65

Not only do we not know how to predict how long a software project will take, we don't even know how to predict what the end product will look like. So who are we kidding? Another way to look at it: take a small one-person project and assign it to three different developers. You may get wildly different results. How could you have predicted those differences in advance? Let alone apply that type of prediction across…

Excellent point.

Can you share your presentation or at least some of your thinking behind it?

Based on what you know, how do you frame this problem? Imagine you had an impressionable audience of 10,000 software professionals (C-level people, managers, developers, UX people, customer support, and so on).

Re: Software effort estimation is mostly fake research

#287

Post by brlewis »

nautilus12 wrote: post #243
BowBun wrote: post #100

It's unfortunate that this HN thread has been reduced to the generic discussion about software estimates when the article is specifically talking about research done on the topic of software estimates. According to the article, proper research remains a struggle due to outdated datasets from before modern agile methodologies, and that the modern datasets from industry are hard if not impossible to gather. If industry…

Dont be so hard on HN, I would say given how niche the actual article topic is, the more generic discussion about software estimation is both relevant and relatable.

I'll be hard on HN here. The more generic discussion is barely relevant to the article. It's a prime example of people seeing an article title as a chance to say something they've already been thinking rather than a chance to read something new.

Re: Software effort estimation is mostly fake research

#288

Post by xpe »

kylecordes wrote: post #125

Sometimes a request for an “estimate” is really a request for a promise, quotation, a guarantee that something will be delivered by X time or cost. It's easy to detect this: Gently begin a discussion of how much uncertainty is tolerable, do they want to know the number we are 50% likely to hit? 80%? If you get emotional pushback to discussing uncertainty, they are looking for a promise.

Yes, many of us are too likely to interpret the word "estimate" at face value. It is a wonderful idea to view this instead as only a starting point -- an information-gathering conversation -- as how to provide your customer or other stake-holders what they need.

If you are some combination of lucky, influential, and persuasive, you might have some ability to shape the contours of their expectations. :)

Re: Software effort estimation is mostly fake research

#289

Post by einpoklum »

withinboredom wrote: post #213
einpoklum wrote: post #165

Earlier quoted context omitted.

> These days, I only give estimates in terms of units but without numbers. Hours, days, weeks, months, quarters or years. Then you must be either an independent contractor or have some magical source of job security. I couldn't get away with this kind of estimate.

Probably more to do with personality mix than circumstance. I've had bosses where I could say things like that and get away with it. I've also had bosses where if I said something like that, I'd be packing up my desk.

Ok, granted, an enlightened boss might accept that kind of estimate, I suppose. And without the higher-ups breathing down his/her neck.

Re: Software effort estimation is mostly fake research

#290

Post by commandlinefan »

lixtra wrote: post #143
koonsolo wrote: post #136

Earlier quoted context omitted.

I once had a manager that thought he could negotiate estimates. That is like negotiating with the weatherman about the weather. Sure, maybe in the end you can convince them it will be finished sooner. But the fact is that it really doesn't change reality.

Typically there are many dimensions to a solution, the negotiation can be about trading one dimension for another. - does it have to be instant or can we run it as a batch - maybe it’s enough to have this tool in English only Etc.

In my experience, the sort of people who believe in negotiating estimates are also the sort of people who only believe there's one dimension that can be traded off: how much unpaid overtime will the developer work?
Post reply on HN