> And civil engineering is just one branch of engineering, there are many and all of them have to work with the same balance between available resources, time and other constraints and they do substantially better than your average software project.
That's the main point that I would like to refute.
Given the regulatory barriers, enormous costs, and long planning timelines for most civil engineering projects, isn't it astonishing that bad designs impacting human lives are still being implemented.
If the process of civil engineering was so well understood, so carefully documented and supervised, and so rigorously taught to new engineers, why are many hundreds of people killed every year?
The uncomfortable answer is that the civil engineering process is very far from well understood - just like software.
> Given the regulatory barriers, enormous costs, and long planning timelines for most civil engineering projects, isn't it astonishing that bad designs impacting human lives are still being implemented.
Well, depending on context, country and corruption: those are the exceptions, not the rule and the engineers typically did their work as well as was possible given the constraints. They know what they know, and more importantly, they know what they do not know and they will engineer in safety factors.
Buildings and bridges collapsing, machinery exploding: those are the exceptions, not the rules.
As a rule, highways function, as a rule, bridges withstand their design loads and excess of those loads and so on.
As a rule: software is buggy, frequently crashes, hogs memory, is slow and has inconsistent user interfaces, updates will randomly break stuff and it is insecure to boot.
If you feel that software is on par with the rest of the engineering disciplines then I probably won't be able to convince you that it isn't.
But whoever designed this bridge and the foundations did a pretty good job of it:
It looks like the bridge designers defeated the the bridge destroyers - in that case at least.
I DO feel that software engineering is on par with other engineering disciplines - if writing software can be described as "engineering".
The important difference with software is that "the code is the design". The code is not the product.
The manufacturing, building and deployment steps in software are actually quite well understood, and has been mastered by most organizations and individuals.
> The manufacturing, building and deployment steps in software are actually quite well understood, and has been mastered by most organizations and individuals.
If we substitute 'some' for 'most' then we're in agreement, unfortunately my experience to date does not give me the confidence required to subscribe to your version, but that could easily be local variation.
That's the main point that I would like to refute.
Given the regulatory barriers, enormous costs, and long planning timelines for most civil engineering projects, isn't it astonishing that bad designs impacting human lives are still being implemented.
If the process of civil engineering was so well understood, so carefully documented and supervised, and so rigorously taught to new engineers, why are many hundreds of people killed every year?
The uncomfortable answer is that the civil engineering process is very far from well understood - just like software.