4 ms·

What makes “real engineering” the correct paradigm (and legal framework) for a profession isn’t the method of delivery, it’s the failure mode and how that align

What makes “real engineering” the correct paradigm (and legal framework) for a profession isn’t the method of delivery, it’s the failure mode and how that aligns with cultural values. In the simplest example: if you ship a car with a bug in its RTOS, people could die. It doesn't matter how easy it is to update. As a culture we’re generally opposed to preventable deaths. In other professions we have set up a regime of legal liability and professional licensing as guardrails and incentives to prevent that failure mode. We should treat software engineering the same, at a minimum in applications where lives are at stake. Other non-lethal failure modes should also be considered (Experian, anyone?). We may have culturally decided by default or accident that data leaks are no big deal. If we actually did think they were important, it would make sense to have licensing and liability frameworks to reflect that. The fact that software has fewer practical constraints than building structures is an excuse masquerading as a reason for not having even the most basic controls in place.

davedx 3y ago
That doesn’t make sense to me. If a software bug can cause a death, like in a car, then the failure modes and legal consequences are the same as traditional engineering. What’s the difference?
- velcrovan 3y ago
  > then the failure modes and legal consequences are the same as traditional engineering Exactly my point! Because the failure mode is the same we should have the same guardrails in place for both. The design and construction of a bridge is independently inspected and verified. The design and implementation of software in a car is not independently inspected and verified. I argue that because the failure modes are the same, we should change the latter to match the former. The design of a bridge must carry the signature of an individual licensed engineer who is personally liable. The design of software in a car is functionally anonymous. I argue that because the failure modes are the same, we should change the latter to match the former.
  - AlotOfReading 3y ago
    The design of software in a car is held to similar standards as the hardware in a car, as one of the people who sign off on it (and not a PE). The software often is independently inspected and verified as part of homologation. Adding a scapegoat engineer wouldn't do anything meaningful except ruin one dude's career when something happens because 1) automotive manufacturers don't fall under engineering firm regulations 2) one person cannot have meaningful technical oversight over the scope of a vehicle, and 3) there is no software PE accreditation process in the US.
    - velcrovan 3y ago
      You are begging the question. The three statements in your list are indeed true. I am saying that they should not be true.
      - AlotOfReading 3y ago
        They've been true for over a century at this point though. Since I assume you aren't complaining about every vehicle ever produced not being signed by PEs, what is it about software that you think it should require a PE stamp when hardware should not?
        velcrovan 3y ago
        > They've been true for over a century at this point though. The duration of the status quo doesn’t feel at all relevant to my argument. > what is it about software that you think it should require a PE stamp when hardware should not? Any profession of system design whose failure mode is “people die” would better serve a culture that abhors preventable deaths if governed by the same licensure, liability, professional ethics and independent verification used by electrical and structural engineering. I don’t make any distinction between hardware and software, but this article happens to be about software, so that’s what we’re discussing.
  - zeroonetwothree 3y ago
    Is the design and implementation of the hardware in a car independently inspected and verified?
- phone8675309 3y ago
  > If a software bug can cause a death, like in a car, then the failure modes and legal consequences are the same as traditional engineering. They are not even remotely. A business may have to pay out a settlement, and failure may attract the interest of regulators (say, the NTSB if it is a car or airplane or the FDA if it's a medical device), but nobody is going to lose their license to practice "software engineering" nor face professional sanction even if there is professional malpractice. The fact that nobody has gone to jail or had their ability to work in software revoked as a consequence of the 737 Max incident is proof that they are not even remotely similar. Had an aerospace engineer certified a physical part the same way that the software engineers certified that software they most certainly would have been on the hook individually for massive damages and would never work in industry again - both because they'd have been named and shamed in the investigation and because likely their license to practice engineering would have been revoked.
- Enginerrrd 3y ago
  >What’s the difference? The difference is that as a civil engineer, when I put my stamp on something and become Engineer of Record, I am personally liable for defects in my engineering, in perpetuity, no matter who I go on to work for later. I can lose my personal wealth, freedom, license and livelihood if it's particularly egregious.

davedx 3y ago

That doesn’t make sense to me. If a software bug can cause a death, like in a car, then the failure modes and legal consequences are the same as traditional engineering. What’s the difference?

velcrovan 3y ago
> then the failure modes and legal consequences are the same as traditional engineering Exactly my point! Because the failure mode is the same we should have the same guardrails in place for both. The design and construction of a bridge is independently inspected and verified. The design and implementation of software in a car is not independently inspected and verified. I argue that because the failure modes are the same, we should change the latter to match the former. The design of a bridge must carry the signature of an individual licensed engineer who is personally liable. The design of software in a car is functionally anonymous. I argue that because the failure modes are the same, we should change the latter to match the former.
- AlotOfReading 3y ago
  The design of software in a car is held to similar standards as the hardware in a car, as one of the people who sign off on it (and not a PE). The software often is independently inspected and verified as part of homologation. Adding a scapegoat engineer wouldn't do anything meaningful except ruin one dude's career when something happens because 1) automotive manufacturers don't fall under engineering firm regulations 2) one person cannot have meaningful technical oversight over the scope of a vehicle, and 3) there is no software PE accreditation process in the US.
  - velcrovan 3y ago
    You are begging the question. The three statements in your list are indeed true. I am saying that they should not be true.
    - AlotOfReading 3y ago
      They've been true for over a century at this point though. Since I assume you aren't complaining about every vehicle ever produced not being signed by PEs, what is it about software that you think it should require a PE stamp when hardware should not?
      - velcrovan 3y ago
        > They've been true for over a century at this point though. The duration of the status quo doesn’t feel at all relevant to my argument. > what is it about software that you think it should require a PE stamp when hardware should not? Any profession of system design whose failure mode is “people die” would better serve a culture that abhors preventable deaths if governed by the same licensure, liability, professional ethics and independent verification used by electrical and structural engineering. I don’t make any distinction between hardware and software, but this article happens to be about software, so that’s what we’re discussing.
- zeroonetwothree 3y ago
  Is the design and implementation of the hardware in a car independently inspected and verified?
phone8675309 3y ago
> If a software bug can cause a death, like in a car, then the failure modes and legal consequences are the same as traditional engineering. They are not even remotely. A business may have to pay out a settlement, and failure may attract the interest of regulators (say, the NTSB if it is a car or airplane or the FDA if it's a medical device), but nobody is going to lose their license to practice "software engineering" nor face professional sanction even if there is professional malpractice. The fact that nobody has gone to jail or had their ability to work in software revoked as a consequence of the 737 Max incident is proof that they are not even remotely similar. Had an aerospace engineer certified a physical part the same way that the software engineers certified that software they most certainly would have been on the hook individually for massive damages and would never work in industry again - both because they'd have been named and shamed in the investigation and because likely their license to practice engineering would have been revoked.
Enginerrrd 3y ago
>What’s the difference? The difference is that as a civil engineer, when I put my stamp on something and become Engineer of Record, I am personally liable for defects in my engineering, in perpetuity, no matter who I go on to work for later. I can lose my personal wealth, freedom, license and livelihood if it's particularly egregious.