Exactly. I worked at Boeing for a couple years (on a different aircraft project, on software tools that would never fly on an aircraft), and my boss made it ve

Exactly. I worked at Boeing for a couple years (on a different aircraft project, on software tools that would never fly on an aircraft), and my boss made it very clear that our job was not to make sure the airplane didn't crash. It was to make sure if anything went wrong, we had the proper paper trail. As a software person, this led to some results that seemed rather counterintuitive. Then again, this level of detachment seems necessary for complex systems. The chef at your favorite restaurant doesn't personally test all raw ingredients to ensure they're safe. They get them from a reputable source, and make sure they're stored and prepared properly when under the restaurant's care. I suspect that this concept is foreign to much of the software world (and hopefully only temporarily) because our raw ingredients are so low quality, and there's no regulation or certification. Half the libraries I'm using (even first-party ones) have significant bugs that I have to work around. If instead of workarounds I just said "That bug you found is actually a bug in <library X>", my app would be completely unusable, and there's be no upstream pressure for these libraries to ever get fixed.