3 ms·

Being a pretty big process guy... I have to agree with SilkRoadie here. I should preface this by saying that my experience comes from developing FDA regulated m

by bilbo0s 12y ago

Being a pretty big process guy... I have to agree with SilkRoadie here. I should preface this by saying that my experience comes from developing FDA regulated medical diagnostic software and not automobiles. So I realize there may be a significantly lower quality threshold that GM is obliged to meet. Having mentioned that, I can tell you that, at least in that medical diagnostic software startup, the idea that an engineer could design and implement ANYTHING and get it into the software build without QA noticing is somewhat fanciful. Someone from QA would have had to be in on it. The process and company structure pretty much made it impossible for the the type of situation outlined in the article to occur. Just as a 30,000 ft overview of the process... imagine a place where every little change required a minimum of 4 signatures, engineer, QA engineer, Head of QA/Reg, and CEO. This allows not only QA, but also the FDA to determine precisely who was responsible for each change. Imagine further that the signatures have to be on paper, and that giant mass of paper documentation has to be submitted to the FDA, along with mountains of other documentation as well as the software itself, for approval. (But everyone understands that it's also submitted so that the FDA knows who to throw in prison if serious bugs crop up.) The situation outlined in the article should be STRUCTURALLY impossible as well. At the startup I worked at for instance, build engineering was under QA. This meant that a development engineer could not give the build team a build directive. Only the head of QA/Reg could do that. Also, the head of QA/Reg didn't report to the COO or CFO or Chief Counsel or anything like that, she reported directly to the CEO. As well, she was a frequent contributor at board meetings. There was just no way to pull an end around on her. That's just a rudimentary outline of the controls we had in place at that startup. Believe me, it actually got a WHOLE lot more restrictive than what I've outlined, but the other stuff is not important to the point I'm trying to make. And that point is this... While I realize that for cars the safety standard is probably lower than it is for medical imaging and RTP packages, you would think GM would have those rudimentary controls in place at a minimum ???

benjamincburns 12y ago
Unless you've got a series of physical safety measures (think GoldenEye style dual keys), your processes are just a series of rules. Enforcement of these rules is probably quite redundant, but I promise you that with sufficient motivation someone high enough in your company could knowingly insert (or cover up) flaws which could kill somebody. Such motivation might come from the fear of losing your job.
- bilbo0s 12y ago
  Well... yes... we had "dual key" type things going on as well. (That was part of what I meant by "it got a WHOLE lot more restrictive".) But, really, isn't an "engineer", someone pretty LOW in the hierarchy ? I mean, that's kind of the point, the better the structure and processes... the higher up you will need to go to subvert them. In the case of GM... the processes were so poor that you didn't need to go beyond the engineer level to subvert them. (Assuming the information in the article is to be believed.)
  - cmdrfred 12y ago
    I imagine that it may have been somewhat simple for GM to implement a system to prevent this, but from another perspective I also can conceive that such a system might effect GM's bottom line negatively. If having engineers cut corners on their own (likely with the encouragement of management) saves money, incompetent upper managers might pad their bonuses with these little cut corners(an out of spec switch here, a faulty connection there). Normally this just means small problems for consumers down the line, this time it just ended up killing people. So who gets blamed? The guy at the bottom? I'm not buying it.

by bilbo0s 12y ago

benjamincburns 12y ago

Unless you've got a series of physical safety measures (think GoldenEye style dual keys), your processes are just a series of rules. Enforcement of these rules is probably quite redundant, but I promise you that with sufficient motivation someone high enough in your company could knowingly insert (or cover up) flaws which could kill somebody. Such motivation might come from the fear of losing your job.

bilbo0s 12y ago
Well... yes... we had "dual key" type things going on as well. (That was part of what I meant by "it got a WHOLE lot more restrictive".) But, really, isn't an "engineer", someone pretty LOW in the hierarchy ? I mean, that's kind of the point, the better the structure and processes... the higher up you will need to go to subvert them. In the case of GM... the processes were so poor that you didn't need to go beyond the engineer level to subvert them. (Assuming the information in the article is to be believed.)
- cmdrfred 12y ago
  I imagine that it may have been somewhat simple for GM to implement a system to prevent this, but from another perspective I also can conceive that such a system might effect GM's bottom line negatively. If having engineers cut corners on their own (likely with the encouragement of management) saves money, incompetent upper managers might pad their bonuses with these little cut corners(an out of spec switch here, a faulty connection there). Normally this just means small problems for consumers down the line, this time it just ended up killing people. So who gets blamed? The guy at the bottom? I'm not buying it.