That almost sounds like you're absolving the engineers (as though they can do no wrong). Changing a part, without also changing it's part-number, doesn't sound like a normal thing to do (and then forget about).
This is a complex issue and I do not agree with the (over-simplistic) reduction to 'management' and 'deadlines'.
Not absolving the engineers. The engineer in this case - and other cases - may well be guilty - both legally and morally - of mistakes.
What I'm trying to understand is, what would make an experienced senior engineer prefer such shortcuts over doing the right thing.
The article says, "Faced with a deadline, DeGiorgio replied: If increasing the torque will destroy the switch then do nothing. Maintain present course. Under no circumstances do we want to compromise the electrical performance of the switch.".
I interpret it as the deadline being a root cause. At the heart of any complex issue lies one or more root cause(s). What were they here? What made him behave that way? Fudging the records is a consequence, not a root cause.
>What I'm trying to understand is, what would make an experienced senior engineer prefer such shortcuts over doing the right thing.
Organizational failure. An onerous documentation change/approval management scheme. Covering up a mistake. A culture that causes people to fear losing their jobs, especially for cost reasons, or the feeling that company management are looking for reasons to cut staff. Having your group be blamed for an expensive product recall makes you an easy target. One of the last things a middle-aged engineer in the US auto industry wants to be right now is laid-off.
We naively expect a senior engineer to do the ethically correct thing without respect to whether it has negative personal consequences. The problem with this idea is that the consequences for being "that guy" are too great; and both engineering societies and state licensing boards have been derelict in their roles of helping to protect engineers who refuse to do the ethically gray/wrong.
>I interpret it as the deadline being a root cause. At the heart of any complex issue lies one or more root cause(s).
There are so many things wrong with product engineering management, but yeah laying a deadline that no engineer has the courage to break would definitely be one of them.
It doesn't sound like such a horrible position to be in; working for a multi-billion dollar company that was trying to force you to ship a part that could kill people. Whistleblowers get 1/3rd of damages, it's like wining the lottery for ethical people.
How long does it normally take to design one of these switches, when you've been doing it most of your life? Knowing absolutely nothing about the complexity of these switches, but knowing what small hardware teams have been able to accomplish at companies I've worked at, 3 years sounds like a more than reasonable time frame.
>It doesn't sound like such a horrible position to be in; working for a multi-billion dollar company that was trying to force you to ship a part that could kill people.
It's probably not a case of some moustache twisting monocle wearing fiend who was the manager and the engineer was absolutely convinced that it was a faulty part that would ultimately be responsible for death and destruction. It was more likely one of a number of similar sub-assemblies, all having some questionable attributes and people trying to ship things under the guise of "perfect is the enemy of the good". At some points along this road, various people probably began realizing that there was a real problem, one that they might have some culpability in. Why the people involved continued to make poor decisions, I don't know.
>Whistleblowers get 1/3rd of damages, it's like wining the lottery for ethical people.
It's a nice theory. I've yet to see it happen consistently in practice (or pretty much ever). Engineering ethics case studies are littered with cases where engineers tried to alert management of problems and were punished for their efforts.
>How long does it normally take to design one of these switches, when you've been doing it most of your life?
Not very long given ample resources and nothing else to do. I doubt they were working under those conditions.
Engineering is the art of technical and economic tradeoffs. Engineers use their judgement, experienced engineers simply have a larger pool of good and bad judgements to draw on. They still get things wrong for the same reasons Uncle Bob has to debug the code he writes, they're human and make mistakes.
The domain of automobile use encompasses more variables than a website - there's no sleet over TCP/IP and broken internationalization doesn't result in crushed vertebrae. The vast majority of software engineers and programmers live in a world where the calculus for balancing technical/economic tradeoffs don't involve life safety and billions of dollars of capital investment in the pans.
You're taking four words from an article (not original sources) and deducing a root cause. In the absence of those four words -- which is the only time 'deadline' is mentioned -- would you draw the same conclusion? I do not.
I could argue that fudging the records is a 'root cause' of why the investigation took longer. If you want to go reductio ad absurdum then really the root cause is ultimately human fallibility.
> then really the root cause is ultimately human fallibility.
I'm not sure why you see this as 'absurdity', because it is a problem and it is something we try to design around with everything from good UIs to fatigue management.
I see it as absurd because when you get to that level, there's no information about what you can practically do to fix it. You've gone way past the threshold of usefulness — if you get my meaning (in other words, this reductionist view could end with "because, physics", but that's not very helpful).
You don't attempt to fix human fallibility itself but instead create systems and process to reduce both it's likelihood and impact (as you describe) for specific scenarios. Those systems and processes can then be improved and new scenarios added.
In this particular case, I find the reduction to 'management and hard deadlines' to be a useless summary (as well as incorrect) as it goes beyond the threshold.
> I see it as absurd because when you get to that level, there's no information about what you can practically do to fix it.
I disagree. I see it as important to recognize our shortcomings and find successful ways to deal with them. It may be that we haven't yet figured this out in general, but figuring out specific cases may allow us to solve individual pieces of the problem one at a time and improve things even if we cannot fully overcome our flaws.
> Changing a part, without also changing it's part-number, doesn't sound like a normal thing to do (and then forget about).
This really depends. If the original part was not being made to spec and the "new" part was to spec, the specs never changed and therefore the part number shouldn't change. They would just identify that parts with serial numbers or stamp dates up to X were not made to spec or defective.
This is a complex issue and I do not agree with the (over-simplistic) reduction to 'management' and 'deadlines'.