I remember going to a conference in the 1980s (MacHack), and attending a "Software Project Estimation" workshop.
The guy basically listed excuses for padding the estimate.
Steve McConnell wrote a book about it, using a much more rigorous scientific methodology[0]. He has also written some other stuff about it[1].
This one is really the big one:
"9. Both estimation and control are needed to achieve predictability. "
In my experience, we can accurately estimate software projects that have iron-fisted control. No deviation from the plan. If we use quality-first techniques, like TDD, we can do a fairly good job of hitting targets.
Also in my experience, this results in software that no one wants to use. It doesn't crash, ticks off the punchlist, and basically sucks.
I avoid estimates like the plague (a rare luxury, but I can do it). I like to "wander down the garden path, and see what sights there are," so to speak. I call it "paving the bare spots."[2]
It results in software that comes very close to the user/stakeholder "sweet spot," with great quality. It also tends to come together fairly quickly, and allows for excellent early project visibility.
But that won't work, beyond a fairly humble scope.
The guy basically listed excuses for padding the estimate.
Steve McConnell wrote a book about it, using a much more rigorous scientific methodology[0]. He has also written some other stuff about it[1].
This one is really the big one:
"9. Both estimation and control are needed to achieve predictability. "
In my experience, we can accurately estimate software projects that have iron-fisted control. No deviation from the plan. If we use quality-first techniques, like TDD, we can do a fairly good job of hitting targets.
Also in my experience, this results in software that no one wants to use. It doesn't crash, ticks off the punchlist, and basically sucks.
I avoid estimates like the plague (a rare luxury, but I can do it). I like to "wander down the garden path, and see what sights there are," so to speak. I call it "paving the bare spots."[2]
It results in software that comes very close to the user/stakeholder "sweet spot," with great quality. It also tends to come together fairly quickly, and allows for excellent early project visibility.
But that won't work, beyond a fairly humble scope.
[0] https://www.amazon.com/Software-Estimation-Demystifying-Deve...
[1] https://stevemcconnell.com/17-theses-software-estimation/
[2] https://littlegreenviper.com/miscellany/the-road-most-travel...