by Kerrick on 3/30/25, 5:26 PM with 71 comments
by variaga on 4/2/25, 12:52 PM
1. An initial estimate is made that is fairly accurate.
2. Someone in management says "that's too long, we've got to find a way to bring in that date"
3. The estimate is revised to assume the best case possible execution time in each task, that resources will be available as soon as they are needed, that everything is fully parallelizable.
4. The estimate now magically matches the target date.
5. Actual execution time is close to the original estimate.
People make bad estimates because (other) people don't want good estimates.
by brudgers on 4/1/25, 5:54 PM
1. People have been doing it long enough that estimator is a job description.
2. That it is a job description, means money is spent on estimation.
3. Money is spent on estimation because getting it wrong can cost money.
I think the problem with software estimation is that there is usually no culture of estimation, usually very little direct incentive to get it right, and no regime of formal training for those responsible.
To put it another way, software does not have standard documents for estimating.
by mattferderer on 4/2/25, 12:57 PM
Overall this is a nice short summary on the topic. The one thing I would add that I found very helpful on larger projects is communicating the risks & unknowns. I suggest listing them out at the start of the project & update their status as you work on it.
I've worked on teams where it's done with a simple color (red, yellow or green) on how confident we are on the task estimate based on risks/unknowns. This is the simplest way in my opinion.
I also like Basecamp's Hill Charts - https://3.basecamp-help.com/article/412-hill-charts
by gedy on 4/2/25, 1:43 PM
At this point I feel Kanban style priorities and limiting work in progress to be only useful approach.
When some product person dumps a huge task in the priorities, break it down into smaller deliverables. No estimates are really needed.
by donatj on 4/2/25, 1:12 PM
Sales people figured out they could come to me specifically for estimates because they would be shorter than other developers estimates and more likely to get the sale. I was young and dumb and didn't connect that often times I wouldn't be the one developing the project. The other developers got angry with me after they caught on to why they were getting impossible timelines.
I started multiplying my personal estimates by three. The sales people were less than pleased and eventually started going elsewhere for their estimates as greener developers were hired.
by didgetmaster on 4/2/25, 3:03 PM
With software, the basic UI can take shape quickly. Some rudimentary functionality sometimes comes along quickly as well. Then all the detail work (error handling, logging, performance enhancements, etc.) makes progress appear to slow significantly.
by myrmidon on 4/2/25, 1:39 PM
But thats just not the point where people typically want estimates, they want them much earlier.
by hkpack on 4/2/25, 1:37 PM
Everything else is just guessing.
Software engineering is not uniform: agencies working on similar projects may have good estimates.
R&D and novel approaches - usually takes whatever time it needs and then some more.
by evklein on 4/2/25, 1:59 PM
by ksec on 4/2/25, 1:03 PM
by hakaneskici on 4/2/25, 3:58 PM
by gilbetron on 4/2/25, 1:35 PM
I'm barely even interested in talking about the subject anymore - estimating software is only useful as an alternative viewpoint to help understand what you are building. Nobody accurately estimates complex software in any meaningful way. Even min/max/most-likely estimation isn't that useful, but ok to think about.
Hidden complexity and simplicity lurks everywhere. "3 month projects" turn into 3 day projects because of an unknown tool. Or a simple problem (think fermat) turns out to be insanely complicated.
The core issue is that when you create a function, or module, or whatever, you never need to do it again. So you are always creating new things. If you are writing the same code again and again, you are bad. Now, the past 10 years or so, that was less true as we wrangled with yaml configs and gluing together pipelines and modules and services. But I think AI is really good at that stuff, so I think we'll be back to always working on original things.
And that doesn't even take into consideration legacy codebases - good luck estimating changes to those ;)
by amelius on 4/2/25, 1:27 PM
by teeray on 4/2/25, 1:23 PM
by zadkey on 4/3/25, 6:44 PM
As they say, "Even a broken clock is right twice a day"
This has been my experience. I don't disagree with the content of the article, really just the exaggerated title.
Every now and again we do get a 100% correct estimation. It doesn't happen often. In fact it's quite rare. But its more than never.
by j_maffe on 4/2/25, 1:13 PM