The reframe
Because writing software is habitually called building, it gets compared to putting up a structure — an activity with known materials, settled methods and predictable durations. The argument is that code is the design document, and that manufacturing from it is automatic and essentially free. Design in every industry is the unpredictable phase, iterated and frequently wrong before it is right. Software looks anomalous only because its design phase is the whole visible project.
Requirements that keep moving
- One answer put the difference in a single comparison: nobody asks for two hundred more seats once an aircraft is on the production line, and yet whole new categories of user routinely appear in a software project after development has begun.
- The change is accepted because it looks cheap. Nothing physical has been cut, so there is no visible waste to argue against.
- The same softness that makes software worth building is what makes its scope hard to hold still.
What the industry lacks
- Standardised ways of breaking a large system into independently estimable pieces, which the accepted answer named directly.
- Agreement on what the units even are, which makes comparison between projects and estimates unreliable.
- Complexity that does not decompose neatly — parts interact in ways that structural components largely do not.
The uncomfortable part
- The premise that other industries deliver large projects faultlessly does not survive contact with their actual record.
- Large construction and engineering projects overrun regularly, and the well-known ones are known for that reason.
- This is not a defence of software estimation, which the thread treats as genuinely poor. It is a correction to the baseline it is being measured against.