[lp4vn]

>I'd be curious to know [...] whether management is actually allowing the quality department sufficient independence to investigate these issues and fully resolve them

If management in the aerospace industry works like management in the software industry, then I guess they are pushing for results as agressively as possible without much concern about safety or anything else.

[cezart]

At a company I worked in, we had a joke about this: "Good thing we don't build nuclear reactors".

In some software projects the level of rush, and the fact that bugs sometimes would leak into production was kinda horrifying. It would've been way more so, if it would've been the kind of project that could kill people in case of failure. Like it happened in Chernobyl with nuclear reactors, or at Boeing with planes.

I can't really imagine what these engineers feel when they rush this kind of work knowing what's at stake.

[toast0]

Quality is always a trade-off. If you're deeply into economics, you wonder about the trade-offs of cost to find defects before shipping, difference in cost of addressing defects before and after shipping including costs of mitigation from consequences of defects, % of defects that will never be found after shipping (and are therefore a real cost savings), and in the long game costs of having a reputation for shipping product with defects that could have been reasonably detected.

In a lot of software organizations with rapidly changing and undocumented requirements, there's a good chance defects will go unnoticed until they're no longer relevant, so spending a lot to find them before they're shipped is a waste. Mitigation of many software defects is simple, but some aren't; hopefully you know which changes are expensive to fix if wrong, so you can more thoroughly vet those.

In Aerospace, addressing defects after shipping is very expensive, and mitigating the effects of defects is only approximate; you can't restore passengers from backup, economic damages don't really make families whole, but should be an incentive not to let reasonably detectable defects be shipped.

[wmidwestranger]

> Mitigation of many software defects is simple, but some aren't; hopefully you know which changes are expensive to fix if wrong, so you can more thoroughly vet those.

This assumes you're fortunate enough to have a defect at the outer edge of the system. Most times, these problems are created in the initial rush of pushing something out and then tax every effort that depends on them, forever, and ever.

[masfuerte]

Amen.

[lp4vn]

>In a lot of software organizations with rapidly changing and undocumented requirements, there's a good chance defects will go unnoticed until they're no longer relevant, so spending a lot to find them before they're shipped is a waste.

It's really a shame that a good percentage of these applications full of bugs and "rapidly changing and undocumented requirements" don't get scrapped and stay many decades afloat until they get replaced by another application also full of bugs and "rapidly changing and undocumented requirements".

I think that that's a very sad way of seeing things honestly.

In the past the USA put the man on the moon, today repeating the same feat looks almost impossible. I bet that a lot of managers at Boeing also think that building planes like a few decades ago looks almost impossible now.

[bbor]

I really find it disingenuous to imply that we can’t build moon rockets because we’re not good enough at engineering projects - I can think of a few engineering projects that took off last year, to say the least. And nasa doesn’t deserve the shade IMO. The kids of the people who built the Apollo program aren’t working at boeing or fighting for one of the few underpaid nasa positions - they’re building reusable rockets for the Twitter CEO, and, much more commonly, parasitic UX features for gig economy apps.

TL;DR: we’re fine at engineering, we’re terrible at resource allocation. Or at least that’s the more relevant cause. I post this knowing full well that this is HN and I might well be disagreeing with a senior nasa employee…

[TheOtherHobbes]

If we're fine at engineering, why are doors falling off planes?

I don't think you can say "We're fine at engineering but we're often terrible at management."

They're not separate things.

Engineering culture is about inventiveness, pride, craftsmanship, and getting the job done well. Bean counter culture is the opposite of all those. If that's the culture engineers work under not only do none of them happen, but they become less and less possible over time.

[bbor]

You’re making great points about the software/engineering industry and I don’t disagree about any of those specifics — engineering culture is paramount. I was just trying to point to (what I see as) the root cause: the engineering culture at Boeing didn’t fall apart because it’s run by lazy millennials or because the managers hadn’t read Mythical Man Month, it’s because they spent their money on stock buybacks and executive compensation.

Funnily enough, I went looking for Boeing stock buyback info and found this article… seems my hypothesis has some specific backing in this case!

Opinion | Did Stock Buybacks Knock the Bolts Out of Boeing? https://www.commondreams.org/opinion/boeing-safety-stock-buy...

[maxerickson]

Quality is always a trade-off.

That's a pretty huge assumption.

For instance, compare firearms prior to replaceable parts to firearms after.

Better, cheaper, easier to make (because craft was replaced with process). Some up front cost, but absolutely not a trade off, it was a huge advancement.

Of course modern process control does more or less let you relax conformance rules to reduce cost, but it's farcical to call sacrificing reasonable conformance "quality".

Arguably, the idea that quality is obviously a trade off and you can make money by letting it slide is one of the sources of rot in our society.

[sokoloff]

> Some up front cost, but absolutely not a trade off, it was a huge advancement.

Any exchange of higher fixed costs for lower marginal costs (or other benefit) is a tradeoff.

This is a tradeoff that was/is massively beneficial, but it’s still a tradeoff.

[maxerickson]

It's not a quality trade off, which is at least implied to be what I am talking about in my comment.

Saying "Quality is always a trade-off" implies you can't actually make things better over time. I would accept something like "You can always trade off of the quality you are capable of producing to reduce costs", but the point is that capability can in fact change, and thus there are ways to improve quality that may not be a trade off (because they also improve the business/system along other dimensions). Even simple little things like aligning a process with the intended outcome can reduce costs while improving quality, you don't have to invent a revolutionary method of manufacturing.

[sokoloff]

Beyond a very early point in any engineering effort (where fruit might be not just low-hanging, but actually lying on the ground), nearly everything is a trade-off.

Those trade-offs (higher fixed costs in exchange for lower marginal costs and higher quality) can be wildly beneficial overall but finding large Pareto improvements against every dimension is rare in anything even remotely mature.

[Turing_Machine]

As the old saying goes: "Fast, cheap, or good. You can pick a maximum of two."

[trompetenaccoun]

That's not how it traditionally worked in aerospace. Commercial airliners are such a safe mode of transportation because from start to finish there are (or used to be?) very high safety standards all around. I can't speak for what's going on with Boeing currently though. Things certainly seem to have deteriorated.