You seem to want estimation. And you will keep doing exactly that, "wanting", because estimation isn't something that scales to big projects or multiple ones.
You seem to want estimation. And you will keep doing exactly that, "wanting", because estimation isn't something that scales to big projects or multiple ones.
If we had something like a detailed blueprint before writing a line of code and the requirements were set in stone we could get a lot closer to other engineering disciplines in terms of predictability.
With the kinds of planning and estimating processes we do actually use you’re lucky to get within a factor of two of reality.
But there's also a step back -- how long does it take you to fully design, but not program, a particular piece of software? If you give a general contractor a particular set of blueprints, he can tell you roughly how long it will take to build, both the ideal number (if there are no scheduling or shipping delays) and what it probably will end up being. But if you tell an architect you want a design for a particular size and purpose and style of building, she can also tell you roughly how long it will take to draw that up.
How long does it take to design a particular piece of software? What makes a design take a day or a month to iron out, well enough that you can get a correct estimate of the amount of time it will take to build it?
I don't think we're good at that, as a profession.
We aren't. And, as an industry, we have managed to convince ourselves that's a good thing. Agile methodologies, after all, are an attempt at making such efforts unimportant.
Estimates in civil engineering are going to look just as bad as software if it was common to keep adding floors of different sizes to a building after it was complete followed by a “pivot” of turning the building into a support structure for a suspension bridge.
Software that is as rigid as tradition engineering projects in the real world can certainly be estimated, this happens in safety critical stuff all of the time. But the estimates are long, and requirements cannot change without massive delays, which is terrible for most software use cases.
Software companies don't do this much. I've worked at only one that charged for changes, and -- surprise -- such changes were very rare.
Source: this is what my Dad did for a living, and I spent a couple of years doing it in my twenties.
The requirements changes in construction projects are child’s play compared to the ridiculous stuff in software. “Oh, now that we have this data visualization app finished, please add in support for collaborative visualization exploration with synchronized views and voice chat.”