Think about it for five minutes. Whatever number you come up with, multiply by 5. Estimate done. The only problem is that management won’t want to listen.
Software effort estimation is mostly fake research (2021)
161–170 of 212 posts
Re: Software effort estimation is mostly fake research (2021)
#162Earlier quoted context omitted.
I hate to say it but from my 20+ years in the industry, this is the norm.
You are absolutely correct, but there are groups within companies that don't work like that. Finding them is the hard part :|
I think it mostly correlates with how technical PMs are.
People that were fairly technical prior to deciding to move to PM roles, those you can actually explain the context and reason with.
PMs that are more biased towards Business/Marketing are big on C Level networking etc., those are the ones that feel they are doing a good job if they try to bleed a stone with deadlines. They are adversarial like GP mentions and not someone you can reason with.
Re: Software effort estimation is mostly fake research (2021)
#163Earlier 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.
Sure. But software is infinitely more complex than movie or any pure hardware engineering
I agree. But the original comment I replied to said:
> Why do software people think they're special?
And the answer to that is: software is complicated.
Re: Software effort estimation is mostly fake research (2021)
#164Earlier quoted context omitted.
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.
Indeed, management is very much about shielding the team, and getting rid of roadblocks.
These are the kind of managers I will go the extra mile for. Got my back I got your back and make sure you shine.
Re: Software effort estimation is mostly fake research (2021)
#165Whenever 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 unfortunately misplaced - but the general gist is touched on in these:
"Forecasting software project’s completion date through Monte Carlo Simulation"
https://towardsdatascience.com/forecasting-software-projects...
"When will it be done? A data-driven approach to estimating project completion"
https://screenful.com/blog/when-will-it-be-done-a-data-drive...
"When Will It Be Done: Project Forecasting in Kanban(ize)" (product ad)
https://kanbanize.com/blog/project-forecasting/
"Project Forecaster"
https://github.com/rodrigozr/ProjectForecaster/wiki
Ed: forgot this one linked from forecaster above:
”#NoEstimates Project Planning Using Monte Carlo Simulation"
https://www.infoq.com/articles/noestimates-monte-carlo/
And maybe this project is of interest:
https://microsoft.github.io/forecasting/
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) - but I'm not aware of anything out of the box for that.
Re: Software effort estimation is mostly fake research (2021)
#166Why do software people think they're special? Like it's somehow expected that we can predict everything because we're computer geniuses? We would have accurate estimates if only we "scienced" better? If you want to get very good at estimation, do it for a very long time. Then you will see how your estimates would be very accurate if all the other things in the world didn't happen. Just let go of the idea that you wil…
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 way or another people do frequently keep changing things so the parameters are always changing from under your feet.
Re: Software effort estimation is mostly fake research (2021)
#167I 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.
This is the way:
> for each desired change, make the change easy (warning: this may be hard), then make the easy change
- Kent Beck
https://twitter.com/KentBeck/status/250733358307500032
Also related to tfa:
> If you have a month to plan a project in detail, spend it on four one-week iterations developing while you improve your estimates. If you have a week to plan a project, hold five one-day iterations. Feedback cycles give you information and the experience to make accurate estimates.
- Kent Beck, Extreme Programming Explained: Embrace Change (The XP Series)
Re: Software effort estimation is mostly fake research (2021)
#168I feel like the core problem here is one that can never be resolved, because it's the result of two valid but opposing forces. On one hand you have business stakeholders, who can see the business reality - money doesn't grow on trees and runways are very real and scary, so without deadlines companies fundamentally cannot function. On the other hand you have engineers, who either explicitly or implicitly understand th…
> business stakeholders, who can see the business reality
but do not want to understand that technical debt does slow things down, and as such it must be paid back as soon as possible.
> engineers, who [...] understand the other truth
and are oblivious to the fact that giving correct estimates is not the point. Shipping sellable functionalities at the deadline is the point!
If the functionalities were sellable enough, rich documentation and elegant code will come. If they weren't, nobody will have to bother.
Re: Software effort estimation is mostly fake research (2021)
#169It'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…
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 live in reality.
Re: Software effort estimation is mostly fake research (2021)
#170It'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've found if you give realistic estimates, some contracting firm comes in, offers to do it in half the time, grabs the project and then takes 2x longer. Finding stakeholders competent enough to understand this pattern is important. If not, you might as well throw out any estimate and also take longer.