I think that is a perception, but its driven by not being able to "see" the product of the work.

Security breaches, locked in data (poor dB structure or no direct access) reverse engineering undocumented functionality, even just dismantling supporting infrastructure and migration costs are huge. Another huge factor is when business logic is codified and the knowledge is lost from the business and only temprarily held by transient consultants or developers.

An sap project for a single region for a $1bn per year company can easy cost over $10m and no software is being developed, only config, process change and data migration. Never mind increased staff turnover reduced productivity.

But very few people have the experience and expertise to understand what they are really signing up for.

Just think about a 3d model can do for a construction project and what that would look like for code and you can see how poorly we do this really.

This ignores the vast amount of software that interfaces with physical systems. When software fails and causes a rover to crash into the surface of Mars, there is certainly a cost and one cannot trivially start again from scratch. Same even with software that does not interface with physical systems, like algorithmic stock trading.

If Iec 61508 was applied to all software that would also do it.

(Make software actually be engineered)

I agree, but I think the horse is out of the barn in many respects. It will be very hard to get organizations to adopt such standards without being forced to by some regulatory agency, unfortunately, because that constraints adds cost and impacts schedule.

That's without even considering all the kinds of rules-lawyering that would be applied afterwards.

In some ways physical engineering is more forgiving. Consider the cost of a security breach. A bridge can be rebuilt, but data cannot be unpublished.

The people who were on it when the bride collapsed are pretty tough to restore from tape...