> Accurate, precise estimates are more expensive than the actual task itself.
That! That is is.
You CAN get accurate estimates. But the cost of doing so is infeasible for any significant project.
You can break things down into smaller pieces, easier to estimate. But the bigger the overall complexity, the more small pieces you will miss or fail to see. Or fail to see how parts interact. Or fail to recognize how far the influence of some element may reach.
And other reasons estimates turn out wrong.
The difficulty of software estimation was recognized in the 1960's. Again in the 1980s during the microcomputer revolution. And again sometimes more recently. When even the biggest companies, with vast resources, and billions of dollars cannot estimate when their product will be ready, how is a small software team expected to precisely do so. There was a joke of which year Windows 95 would ship in.
At the same time, a business needs some kind of timetable because many other things need to coordinate with the completion of a software project.
Maybe recognize the best you can do is have an idea of how well things are going. As a project gets further along you get a better idea of when it will be complete -- especially when there are lots of unknowns.
When constructing a building, there are lots of knowns. How many square feet. How many walls. Electrical outlets. Plumbing fixtures. Etc, etc. They can give you a very good estimate. It's all things they've done before.
Software is generally things that you've not done before. (or you may suffer the second system effect if it is)
After doing this for 25 years, I always say "you never get good at estimating, you just get less shitty at it"..
Lots of people don't like that statement, but I stand by it..
I eventually stopped trying to estimate time required to deliver a specific thing, and instead started working backwards and seeing what can be done in the time we have.
It's still estimating, but it's somehow a bit easier, especially if you're willing/able to re-evaluate along the way.
I know that's basically Agile but I removed all the ritualistic BS. ;-)
That! That is is.
You CAN get accurate estimates. But the cost of doing so is infeasible for any significant project.
You can break things down into smaller pieces, easier to estimate. But the bigger the overall complexity, the more small pieces you will miss or fail to see. Or fail to see how parts interact. Or fail to recognize how far the influence of some element may reach.
And other reasons estimates turn out wrong.
The difficulty of software estimation was recognized in the 1960's. Again in the 1980s during the microcomputer revolution. And again sometimes more recently. When even the biggest companies, with vast resources, and billions of dollars cannot estimate when their product will be ready, how is a small software team expected to precisely do so. There was a joke of which year Windows 95 would ship in.
At the same time, a business needs some kind of timetable because many other things need to coordinate with the completion of a software project.
Maybe recognize the best you can do is have an idea of how well things are going. As a project gets further along you get a better idea of when it will be complete -- especially when there are lots of unknowns.
When constructing a building, there are lots of knowns. How many square feet. How many walls. Electrical outlets. Plumbing fixtures. Etc, etc. They can give you a very good estimate. It's all things they've done before.
Software is generally things that you've not done before. (or you may suffer the second system effect if it is)