Hacker News Reader

Comment by linuxftw | Hacker News Reader

This article seems to be second-hand reporting some of the information originally broken here [1].

There's a lot of damning information, not only for Boeing, but also a lot of negligence at the FAA for pushing engineers to 'delegate' reviews of certain components back to Boeing themselves.

[1] https://www.seattletimes.com/business/boeing-aerospace/faile...

View on HN

Ok, we've changed the URL to that article from https://qz.com/1574878/pilots-trained-for-boeing-737-max-wit... in keeping with the guidelines' call for original sources. Thanks!

I often submit original scientific articles and reports here that achieve no traction. When I then submit less technical versions appearing in more mainstream media — New York Times, Wired, Verge, The New Yorker, etc. — they frequently appear on the home page, generating hundreds of comments. I'm always in a quandary as to which approach to take: after all, if a tree falls in a forest....

Yes, that's a common pattern. Experience has taught us that it's best to submit the highest-quality popular article on a topic and link to the original paper in the thread. If an article is too specialist-oriented it probably won't do well here regardless of how interesting it is. Papers on computing are an exception, because a significant subset of the audience here is able to read those.

Thank you for this advice. I will follow it.

AFAIK, the FAA, like many regulating bodies take everything at face value, making sure they are not getting lied to isn't their jobs.

An audit usually goes like: "I see that you mentioned a change in document X, show me the corresponding test report", "who is responsible for that part?", "does document Y match document X, as required by norm Z?".

They will never check that you actually did the tests, or that the analysis is correct. Only that the paperwork is done correctly and that the person responsible is identified. Their field of expertise is in the process, not software or mechanical engineering.

But now that they have a list of names, and if one of them rubberstamped something that wasn't actually done, things won't go well for him. It can get really serious, possibly resulting in prison time, so managers usually don't that this duty lightly.

> AFAIK, the FAA, like many regulating bodies take everything at face value, making sure they are not getting lied to isn't their jobs.

I don't think this is accurate whatsoever. USDA has inspections all the time, they don't just check a report you file with them and go "Oh yeah, they know what they're doing over there." Similar with other industries.

If a regulatory body doesn't validate the tests of a manufacturer, what good is that body?

> > AFAIK, the FAA, like many regulating bodies take everything at face value, making sure they are not getting lied to isn't their jobs.

> I don't think this is accurate whatsoever.

Which part, that the FAA encourages delegation to Boeing? This is established, AFAIK.

Regulatory agencies taking things at face value.

It's pretty common all around... it's as much about documenting who to point the finger at as anything else.

I work at a company that builds software for Flight School operators. The operator is required to physically demonstrate our software to a FAA inspector before they can use it. In this case the FAA actually checks that our system works as intended.

That might be true for the FAA, but it's not true for the FDA. They will ask companies for original data and then replicate analyses.

But do they replicate how that "original data" was generated or gathered?

Friend of mine was working for a medical device group. One of the managers removed some negative patient data from the reports they filed with the FDA. The FDA when they figured it out responded with an outright rejection that was final.

No, because the FDA doesn’t have the resources to actually redo a trial.

What they do is ask the manufacturer to lay out how they run the trial before they start.

If you bring data back to the FDA that doesn’t match up (fewer patients, different measurements) you can expect a rejection.

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.

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.

Right. The more paper you have the cleaner your bottom will be.

Reply on news.ycombinator.com