3 ms·

I really don't appreciate this attempt to shift blame away from any group and onto any other group. it's unprofessional and suggests working out who we can poin

by dosy 8y ago

I really don't appreciate this attempt to shift blame away from any group and onto any other group. it's unprofessional and suggests working out who we can point the finger out and convincing people not to point the finger at our group is more important than the tragedy that happened and trying to work out ways to take responsibility for that. I'm sure all systems involved in the failure could be improved in some way. to emphasize how one system is not responsible is not a very empathetic response.

ww520 8y ago
The group you are complaining about, the software people, are already being falsely blamed. This is a rebuttal to that. Just refuse to be a doormat.
- evilotto 8y ago
  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.
- dosy 8y ago
  sigh. It feels scary to feel blamed, I know, and whether you think you're a doormat or not, is important but it's not the main point. The point is, you're not the victims. The people who died are the victims. And pointing the finger, playing the blame game (instead of asking how can we do better in the wake of this tragedy) doesn't honour them, and it doesn't help. Just refuse to be the fake victim. That's weak. Don't make it about you, choose to make it about what can be improved.

by dosy 8y ago

ww520 8y ago

The group you are complaining about, the software people, are already being falsely blamed. This is a rebuttal to that. Just refuse to be a doormat.

evilotto 8y ago
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.
dosy 8y ago
sigh. It feels scary to feel blamed, I know, and whether you think you're a doormat or not, is important but it's not the main point. The point is, you're not the victims. The people who died are the victims. And pointing the finger, playing the blame game (instead of asking how can we do better in the wake of this tragedy) doesn't honour them, and it doesn't help. Just refuse to be the fake victim. That's weak. Don't make it about you, choose to make it about what can be improved.