4 ms·

Accepting responsibility, is not being a doormat. No matter what systemic faults were in play, the software was a part of it, and if the software engineers had

Accepting responsibility, is not being a doormat. No matter what systemic faults were in play, the software was a part of it, and if the software engineers had made different choices - such as refusing to allow a flawed system to go forward - then the outcome would have been different.

speedplane 8y ago
> if the software engineers had made different choices - such as refusing to allow a flawed system to go forward - then the outcome would have been different. You're assuming that the software engineers had sufficient information to identify the system as flawed. The MCAS problems appear to stem from faulty sensor data, we don't yet know much more. However, suppose, for example, that the software engineers were told in by the sensor manufacturer that when the sensor had an error, it would shut off entirely and no signal would be sent. If that was the case, it would be difficult for the software developers to forsee and account for incorrect sensor data, rather than just no data. In something as complex as a commercial airplane, no one person can know all the systems. There has to be information "hand-offs", and it's understandable that the person receiving the information would rely on it. It's not that different in more prosaic software development. If an API has a bug in it, it's hard to blame the API users for not accounting for the bug. You generally trust that the API does what it says it does.
- evilotto 8y ago
  > You're assuming that the software engineers had sufficient information to identify the system as flawed. No, I'm assuming that the software engineers had sufficient information to know what the gaps in their knowledge might be. Following your example, if the engineers were told by the manufacturer that an error in the sensor would result in no data rather than bad data, there should immediately be followup questions: What is the redundant source of data? What is the valid range of data? Is there a positive way to detect and identify errors? How should detected errors be handled? The answers to these questions should be provided by the manufacturer. It may not be the software engineer's responsibility to double-check all the answers, but they do need to check that they were answered in the first place. There absolutely needs to be information hand-offs; blindly accepting such a hand-off does not absolve you of responsibility.
  - speedplane 8y ago
    > No, I'm assuming that the software engineers had sufficient information to know what the gaps in their knowledge might be. ... if the engineers were told by the manufacturer that an error in the sensor would result in no data rather than bad data, there should immediately be followup questions ... Yes, of course there should be due diligence with any hand-off. However, lets assume for the sake of argument that there was, and the engineers using the sensor data received appropriate answers to their questions, and yet still the sensor did not perform as specified. It's hard to blame someone who did their due diligence, did everything right, and relied on ultimately inaccurate information.
    - evilotto 8y ago
      My point (poorly made) is that there is a difference between blame and responsibility. "Blame" is answering the question "who screwed up"; "responsibility" is answering the question "who is going to make this better". The original tweet-stream post was making the argument that the software (and so naturally the software people) did nothing wrong and thus was not to blame, but also made the argument that since everything else was wrong ("not my fault!") that there was nothing the software people could have done to make it better, i.e., they have no responsibility.

speedplane 8y ago

> if the software engineers had made different choices - such as refusing to allow a flawed system to go forward - then the outcome would have been different. You're assuming that the software engineers had sufficient information to identify the system as flawed. The MCAS problems appear to stem from faulty sensor data, we don't yet know much more. However, suppose, for example, that the software engineers were told in by the sensor manufacturer that when the sensor had an error, it would shut off entirely and no signal would be sent. If that was the case, it would be difficult for the software developers to forsee and account for incorrect sensor data, rather than just no data. In something as complex as a commercial airplane, no one person can know all the systems. There has to be information "hand-offs", and it's understandable that the person receiving the information would rely on it. It's not that different in more prosaic software development. If an API has a bug in it, it's hard to blame the API users for not accounting for the bug. You generally trust that the API does what it says it does.

evilotto 8y ago
> You're assuming that the software engineers had sufficient information to identify the system as flawed. No, I'm assuming that the software engineers had sufficient information to know what the gaps in their knowledge might be. Following your example, if the engineers were told by the manufacturer that an error in the sensor would result in no data rather than bad data, there should immediately be followup questions: What is the redundant source of data? What is the valid range of data? Is there a positive way to detect and identify errors? How should detected errors be handled? The answers to these questions should be provided by the manufacturer. It may not be the software engineer's responsibility to double-check all the answers, but they do need to check that they were answered in the first place. There absolutely needs to be information hand-offs; blindly accepting such a hand-off does not absolve you of responsibility.
- speedplane 8y ago
  > No, I'm assuming that the software engineers had sufficient information to know what the gaps in their knowledge might be. ... if the engineers were told by the manufacturer that an error in the sensor would result in no data rather than bad data, there should immediately be followup questions ... Yes, of course there should be due diligence with any hand-off. However, lets assume for the sake of argument that there was, and the engineers using the sensor data received appropriate answers to their questions, and yet still the sensor did not perform as specified. It's hard to blame someone who did their due diligence, did everything right, and relied on ultimately inaccurate information.
  - evilotto 8y ago
    My point (poorly made) is that there is a difference between blame and responsibility. "Blame" is answering the question "who screwed up"; "responsibility" is answering the question "who is going to make this better". The original tweet-stream post was making the argument that the software (and so naturally the software people) did nothing wrong and thus was not to blame, but also made the argument that since everything else was wrong ("not my fault!") that there was nothing the software people could have done to make it better, i.e., they have no responsibility.