Live data from Hacker News

Software effort estimation is mostly fake research (2021)

shape-of-code.com

201–210 of 212 posts

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

#201
post #26

Earlier quoted context omitted.

> 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.

Which plans? There weren't any, just rough sketches, plus the requirements were constantly changing. They also started construction before the planning was finished.

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

#202
post #181

Earlier quoted context omitted.

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.

Sure, I can give estimates that don’t underestimate and account for eventualities. It’s just that my error bars are large enough that in that case I have to estimate several months for tasks that I believe should take a week.

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

#203
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…

Don't forget to multiply by the square root of 2 (management overhead coefficient). Also note that this is an irrational number so it has a subtle jab at management built-in.

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

#204
post #166
post #53

Earlier quoted context omitted.

Some industries are pretty good at estimating effort. Eg when a film crew shoots, they have so many weeks, and they usually manage to shoot the footage for the movie within that time.

One of the big reasons that software estimation doesn't work well is because due to the virtual nature of software it is way too easy to move the goal post in subtle or not subtle ways. In "real world" projects such as civil engineering everything is a lot more stable. You don't start with the intention of building a bridge and decide to turn it into an airport halfway through the project. In software projects one wa…

In the "real world," estimates are also terrible. Even for something as simple and well-defined as repaving an airport runway, research shows the actual cost exceeds estimated cost by a median factor of 1.25.https://ocw.mit.edu/courses/ids-333-risk-and-decision-analys...

Have you ever heard anyone ever say their kitchen renovation project came in under budget? Humans are just doomed to never be good at estimating, in any context, outside the simplest of tasks.

Software has unique challenges that make it inherently difficult, but the bigger problem is all the incessant micromanagement, tooling like Jira that enables management's worst behaviors, and lack of any union representation or solidarity among developers. There's an infestation of libertarians that think they're better than everyone else, that think they can meet these impossible standards. They're too naive to realize that if they did make a miracle happen, management would just move the goalposts again and again, until you burn out, your wife leaves you, and you decide to start farming goats or whatever. We all need to refuse to play no-win games collectively. No estimates is the only answer. They can't fire us all.

Collective action is probably a pipe dream, though. With that in mind, I think half the issues with this career would go away overnight if a Russian ransomware gang erased Jira and Atlassian out of existence. Those grifters are selling the corporate equivalent of fentanyl laced with benzos to middle managers. Jira is poison.

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

#205
post #165
post #14

Whenever the topic of software estimates comes up, I am reminded of Erik Bernhardsson’s piece[1]. It was a great read, and still proves useful when trying to explain how things can sometimes go quite wrong. [1]: https://erikbern.com/2019/04/15/why-software-projects-take-l... Edit: it has come up a few times on hn. See https://news.ycombinator.com/item?id=19671673

This is great, thank you. Another approach is to do forecasting based on historical throughput (eg tasks/day). Generally using "story points" or other guesstimates turn out to be redundant if you have actual data (actual project by mostly the same team). It takes into account stuff like n% of issues "blowing up" into subtasks, and some issues taking longer. I read a great article on the subject which I've unfortunate…

That was quite fascinating. Thanks!

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

#206
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…

what if the room temperature is 0?

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

#207

Earlier quoted context omitted.

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 p…

This is exactly my problem with software dev. There are no standards, no expectations, hardly any regulation. Employers grab fresh graduates and throw them right in the deep end and hardly anyone looks at their work or teaches them anything.

In Norway if you want to be a carpenter or plumber or electrician you have to be an apprentice for two years after your education and then do a test to prove you've learned to do your work properly.

Meanwhile in our field nobody even agrees what properly is, most of us are just here for the money and are planning to job hop in a year so they don't give a crap. Docs? Nah. Unit testing? Nah. Clean code? Nah. That only matters if you give a shit.

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

#208

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…

Management denial is not universal. It can't be - companies that have realistic management should out-compete companies where management is politics and unreality. The problem is that management unreality can take a decade or several to destroy a place. But when you see that kind of management, know that that's the road they're on. That's your cue to start looking for somewhere with management that at least tries to…

You’re forgetting that in companies with the management properties you say are bad, those properties may cause actual value to be delivered faster, even if it’s at long term cost. That value can accrue, gain interest, and that company can be more successful than the one with the management properties you say are bad.

I think you’re conflating success of a company with the pleasure of its employees. These 2 factors are usually (not always) opposing not correlated.

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

#209
post #165
post #14

Whenever the topic of software estimates comes up, I am reminded of Erik Bernhardsson’s piece[1]. It was a great read, and still proves useful when trying to explain how things can sometimes go quite wrong. [1]: https://erikbern.com/2019/04/15/why-software-projects-take-l... Edit: it has come up a few times on hn. See https://news.ycombinator.com/item?id=19671673

This is great, thank you. Another approach is to do forecasting based on historical throughput (eg tasks/day). Generally using "story points" or other guesstimates turn out to be redundant if you have actual data (actual project by mostly the same team). It takes into account stuff like n% of issues "blowing up" into subtasks, and some issues taking longer. I read a great article on the subject which I've unfortunate…

Thanks for mentioning Screenful. Just wanted to comment on your remark:

"In general I'd like to be able to just point a tool at N "completed" GitHub projects, and a fresh one - and get a forecast that adjusts as issues are completed and added (possibly filtering on issue tags in completed and new project)"

That's exactly how our Forecasting chart works. You can import any number of repositories and projects (classic or new) and get a forecast for the remaining work. You can learn more about that chart from this guide: https://screenful.com/how-to/how-to-read-the-forecasting-cha...

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

#210
post #41

Earlier quoted context omitted.

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 a…

The more experience you have the more you're used to these things happening. I don't have to know that a specific thing might go wrong but I'm used to there being some random bullshit (weird CI, library happens to be deprecated, version inconsistencies, data turns out to have a fatal flaw, licensing, whatever).

You can't plan for everything though, and you're right this is where a good PM helps.

But then again this is all just estimates. The better you can estimate the better you can plan.

Post reply on HN