"Software engineering" certanly feels better but I think generally our work is closer to a craft than an engineering practice; imagine if we built bridges, tunnels and planes as we build software - catastrophes every day!
As someone who learnt to code as a kid, then studied and worked in civil/structural engineering, then ended up later on back in software, I do find comparisons (somehow always involving bridge analogies) between software engineering and 'traditional' engineering to always be off somehow.
Most traditional engineering projects are not magical bastions of rigor and certainty. It is really only in very large budget or critical projects that a lot of analysis or rigour comes into play to create that certainty.
At least in the civil/structural world you'd be surprised how much comes down to just gut feel by experienced engineers who then throw down some very quick calculations (budgets don't allow for much more than that) to back up their choices. Most numbers are looked up in tables. They then hopefully get run past another experienced engineers gut feel for validation then get signed off. And most of the time the public agency will just accept that uncritically - as they no longer have the resources to double check designs themselves.
The main difference with software as I see it, is that software is binary and the real world is analogue. Civil/structural engineering standards have factors of safety for materials and loading codes etc to cope with inconsistencies or minor mistakes/oversights or unforeseen circumstances etc. Even most failures are not catastrophic and can be detected and fixed before a catastrophic failure eg things can yield or crack rather than snap.
Software being binary though means for a certain set of circumstances it either works or it doesn't. You don't have the luxury of factors of safety and just overspeccing components to be sure.
Thanks. You are right, the comparison is off probably on both sides.
As with critical civil/structural engineering projects, there are software development projects built with correctness in mind. I've worked on a few of those, mostly in aerospace and VLSI simulation in the late 70s til the early 90s, and the level of engineering was very high.
Fast forward two decades to the world of web development and corporate IT and, wow, the lack of rigour is simply abysmal. I can imagine the same been true in the housing/building sector.
Most traditional engineering projects are not magical bastions of rigor and certainty. It is really only in very large budget or critical projects that a lot of analysis or rigour comes into play to create that certainty.
At least in the civil/structural world you'd be surprised how much comes down to just gut feel by experienced engineers who then throw down some very quick calculations (budgets don't allow for much more than that) to back up their choices. Most numbers are looked up in tables. They then hopefully get run past another experienced engineers gut feel for validation then get signed off. And most of the time the public agency will just accept that uncritically - as they no longer have the resources to double check designs themselves.
The main difference with software as I see it, is that software is binary and the real world is analogue. Civil/structural engineering standards have factors of safety for materials and loading codes etc to cope with inconsistencies or minor mistakes/oversights or unforeseen circumstances etc. Even most failures are not catastrophic and can be detected and fixed before a catastrophic failure eg things can yield or crack rather than snap.
Software being binary though means for a certain set of circumstances it either works or it doesn't. You don't have the luxury of factors of safety and just overspeccing components to be sure.