6 ms·

Is their name really important? The deaths weren’t from a bad programmer, they were from a lack of software quality methodology. The entire field of software qu

• hnruss 7y ago
  If I was hurt by some bad code, I’d want to know who wrote it. Bugs happen, but reasonable steps should be taken to prevent them. Developers share that responsibility with management, whether they like it or not.
  • sam_lowry_ 7y ago
    Like Vitaly Kaloyev? And then you'd come at their door to chat about life and death, with a knife in a pocket.
    • slavik81 7y ago
      I would have asked why rather than jumping to accusations, but I too was reminded of the murder of Peter Nielsen. The story of that series of tragedies: https://en.wikipedia.org/wiki/2002_Überlingen_mid-air_collision https://en.wikipedia.org/wiki/2002_Überlingen_mid-air_collis...
  • HeyLaughingBoy 7y ago
    Which part of the "bad code?" The actual line that failed? The code that called it which didn't check a return value? The code below it that always returned the same value regardless of success or failure? The fault in the OS that allowed a race condition because it didn't lock processes properly? Or did the failure happen because the code that was written for an 8-bit controller is now run on a 32-bit controller and no one realized that? Perhaps you'd want to bring in the Test Engineer who verified that the particular feature passed? Why didn't they do their job? How about the Senior QA Engineer who wrote the test cases? Do you also want to know who wrote the Requirement that the code met? Maybe the code did exactly what the Requirements said, but the Requirement was poorly written. Point is, failures have to be analyzed on a Systems basis. Simply looking at a line of code can be completely meaningless and miss the big picture. And yes, each of the above failures is something I've come across in my career.
• praptak 7y ago
  The name is not important. The fact, that they were not found is telling though. Was there no track record of any kind? Edit: It seems there was, as in he was developing alone and the company didn't disclose his identity. Puzzling.
  • londons_explore 7y ago
    The implication is not that nobody could track him down, but instead that nobody in a position to do so did so.
• jeffdavis 7y ago
  It's not important in the sense of "name this guy and run him out of town". But it would be nice if an investigation was completed, and all the facts found by the FDA before it was concluded. Maybe they could have collected information from him in a non-blaming way that would avoid similar disasters in the future.
• sgift 7y ago
  No, it's not. I think it would even have been counterproductive to find that programmer. People would have latched onto "see, it was a bad programmer!" and the real problems could have been forgotten. The investigators did the right thing, they focused on the systematic problems. And the coworkers also did the right thing by not providing someone as a scapegoat.
  • Thorrez 7y ago
    I would think it's easier to blame someone you've never talked to than to blame someone you have talked to. If they had interviewed him, he might have revealed systematic failures in many other parts of the company. But if he's a nameless individual who can't say anything, he can be a silent scapegoat.
  • hhas01 7y ago
    What absolute bullshit. How the hell are investigators supposed to construct a full and accurate assessment of what went wrong and the correct way[s] to remedy it when a key testimony is nowhere to be found? At best it was cowardice; at worst, a deliberate coverup. ISTR that whenever the Lockheed Skunkworks lost a test plane and pilot, the engineers were responsible for explaining to the widow what had gone wrong and what they had done to fix it so that it wouldn’t happen again. That’s what wearing big boy pants really looks like, kid. If you aren’t willing to testify to the shortcomings of your own work and why it is the way it is, you have no business doing it in the first place. Least of all when lives are on the line.
    • saagarjha 7y ago
      Why would you be willing to testify on the shortcomings of your work if you’re going to end up as blurb taken out of context alongside your face as “the Therac-25 murderer” in the news?
• wpietri 7y ago
  People are responsible for their actions. There were many things wrong with this project, but one of them was fatally bad code, which this guy took money to write. Having him be named strikes me as the very minimum in accountability. I think it's also important to name him, to interview him. To understand how he came to kill. So that anybody writing life-critical code today can say, "I'd better not end up infamous like that guy. I can't make the same mistakes." Maybe if he had been held accountable, the programmers at Uber wouldn't have been lax enough to code up the negligent homicide of Elaine Herzberg.
  • adrianN 7y ago
    A culture of blame leads to programmers of safety critical software hiding their mistakes.
    • Jwarder 7y ago
      I can see why you would say that, but isn't classical engineering a counter example? Professional engineers have a culture of accountability and responsibility. No system is perfect, but (to my eyes at least) classical engineering works safely without a culture of blame.
    • mcguire 7y ago
      A culture of refusing responsibility is better how?
      • adrianN 7y ago
        The opposite of a blame culture is not a culture of refusing responsibility, but a system where you look for problems in the process when a fault makes it into the final product. It's always a mixture of specification, implementation, and QA that makes mistakes possible. Putting the blame on the engineer is not very helpful, it does little to prevent future problems. Trying to figure out how it was possible that an implementation bug made it through QA allows you to prevent similar mistakes in the future (at least if you're lucky).
• rowanG077 7y ago
  No but it will generate some sweet delicious outrage that can be used by the media to divert an important issue.