Mostly the harm a software engineer can do will be in monetary losses and not in the loss of life. Also there is the fact, that a lot of the software written will be the process of communication, sparring, feedback and iteration so establishing that a single person is at fault would be hard to prove anyways.
However there are software devs that do have to tread with care (eg. in the automotive sector, defense or medical). The differentiator IMO is who is driving the demand for covering possible liability issues: The private sector or the government.
That by itself (or the cultural differences) shouldn't define what "Engineering" actually means, or should it?
Software engineering as a profession is so immature that we haven't seen many serious incidents yet. But people have died because of bugs. And this will only increase over time as we keep using more and more software.
The real meaning for engineer is someone who builds complex stuff that require years of learning and practice for the majority of the population.
Having a set of defined rules to follow is not engineering, is safety based on previous experience, most car drivers also do that and they are not engineers.
It is a part of being an engineer, but it is not the entirety of the profession (I'd probably use the word Standards rather than rules). I think the software world has standards to for things like networking etc - does it count as a programmer following a set of rules if he writes networked software? Maybe...
>The real meaning for engineer is someone who builds complex stuff that require years of learning and practice for the majority of the population.
I don't think this really fits either. Throughout my career I have spent very little time building anything, a large amount of the work is optimizing existing problems/products/processes (this is where tradeoffs the GP mentioned comes in) "How can this be made cheaper, How can it become more efficient, How can it be made lighter etc."
If I had to come up with my own definition it would be something like "Engineering is solving technical problems within an applied set of Constraints" - That probably does not apply to a surgeon - but could be applied to software.
Maybe we should acknowledge that it’s not as simple to define and that’s why articles like the one posted are writen.
If only this were true for software...
If a car has a poorly-engineered suspension and a wheel breaks off and someone gets killed, does the engineer at Ford who designed it get sued personally? Absolutely not. Did any engineers at Ford who designed the Pinto suffer personally for their design? Of course not.
I believe the laws differ by country. In the above circumstance where I am based (Australia) the person who signed off after reviewing the suspension design would inherit the liability. And may get taken to court where you would need to demonstrate you followed best practices may be ask to supply calculations etc.
For example my company we are required legally to keep things like calculations and technical drawings on file in archives for things like above hypothetical.
No, it's not. Civil engineering is; the rest of them, not so much. The vast majority of engineers in the US fall under the "industrial exemption", whether they work for Microsoft, Google, Ford, GM, Boeing, or General Dynamics, or countless other companies large and small. Almost none of them have a Professional Engineer license.
It's weird how, every time this kind of discussion comes up, civil engineers keep trying to tell all the people who design fighter jets and cars that they're not "real engineers" because they don't have a license.
This is unlike programming, where "self-taught" or "dropped out of college" is sufficient.
To be fair I don't think we even have the tools to create software that we can be liable for yet, not without halting progress to a point where, without strong laws, companies cutting corners would win by iterating way faster.
What the vast majority of us in software do is not engineering. I think like you say liability is one part, but another big part is the immense breadth of unknowns we have to deal with and accept. There's no budget or time given for properly figuring out and scoping a project (for most programming), because the penalty for failure isn't so steep. It's not written in blood, so we don't dedicate the resources necessary to really engineer it.
Some programming is arguably engineering. Many parts of aerospace for example. Some of the medical devices space. But it's overall a very small percentage of total programming happening in that world.
And you know, that's probably okay, for now at least.
What the vast majority of us in software do is not engineering. I think like you say liability is one part, but another big part is the immense breadth of unknowns we have to deal with and accept, but never really chase down. There's no budget or time given for properly figuring out and scoping a project (for most programming), because the penalty for failure isn't so steep. It's not written in blood, so we don't dedicate the resources necessary to really engineer it.
Some programming is arguably engineering. Many parts of aerospace for example. Some of the medical devices space. But it's overall a very small percentage of total programming happening in that world.
And you know, that's probably okay, for now at least.
Also any kind of automation that might kill a human: industry automation, self-driving cars, etc.
In most parts of the software world I don't think there exists similar circumstances. I'm not sure if there are agreed industry best practices or certification requirements for most types of software development.