Nope, that blogspam article misses the mark by a mile. The major difference in almost all software environments is that the software requirements constantly change, even after the initial version is done.
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.
You realize that this sort of requirements change happens all the time in construction projects, right? Granted there are limits to this, but the vast majority of construction overruns are caused by changes in requirements.
It’s still a change before it’s done and it’s pretty constrained. Scope changes too big are just completely impossible because of physical constraints, lack of permits, etc.
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.”
Requirements change in non-software projects but rarely do they change the project into a completely different category like "I know we started building an office tower and it's halfway done, but now the client wants it to be an airport." This happens in software all the time.
Yup, in fact this is the strategy for profit maximisation for many, many construction companies. You look at the plans/requirements and if you spot loads of missing things you bid a low price with high prices for changes and make loads and loads of money.
Source: this is what my Dad did for a living, and I spent a couple of years doing it in my twenties.
It is also the strategy for profit maximisation for many, many software companies. "Change request" is a big deal in outsourced enterprise software dev. It is so bad that 'honest' software development groups that estimate accurately and don't have a culture of change requests cannot compete.
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.