That those seats were coincidentally empty doesn't lessen the seriousness of the event.
If 2 people has died, it would have been a more serious event. By definition, no?
nope for me
I slip on a puddle, but I'm young and nimble so I catch myself. No harm done to me, not a serious incident right? I don't report the puddle. Then another guy comes alone, he's older, his reflexes aren't so good. He bounces his head off the concrete and dies. This is why all workplace safety policies tell you to treat near misses like the real thing. The only difference between them is circumstantial luck.
Especially since I’m not saying it isn’t serious. Just pointing out that 0 < 2 < 189.
Which is quite literally true, is it not?
I thought it was serious, just less serious than those that actually killed people, because it does show system issues at Boeing related to actually doing safe changes to their planes.
Which is a scary operational problem, but at least not a major plane design problem.
Which will kill someone (or a lot of someones!) eventually.
And got called a psychopath for it, apparently? Which doesn’t seem very polite.
Yes, you've been very confused in this entire thread. No, I did not say what you think I've said. In fact, I stated the exact opposite. You seem to have an agenda and are attempting to read that into this entire thread.
There were zero fatalities in this incident. I personally thought it was serious, but less serious than incidents which have fatalities.
Are we agreeing? Who is confused here? Am I a psychopath?
what do you mean unlike the MAX problems? do you think this is a different model aircraft. The MCAS related crashes with 300+ casualties was an earlier version of the MAX. The door flying off was still a MAX.
So at this point, we should be well past viewing incidents on a per incident basis, and now just see each one as yet another example of the failure/lack of Boeing's prowess on designing a safe airplane.
This was an ops problem.
The common element is Boeing, not the model of plane.
Notably, this type of ops issue (managers pushing for high velocity - paperwork and quality of work be damned) is inevitable when output numbers must go up or stay the same even in the face of other pressures increasing.
We’ve all been there for sure - too many bugs coming in, so mark them ‘can’t reproduce’ the first pass through, or if we can’t figure out what is going on in the first couple minutes. Or put a hack into production to fix it now, with an actual real fix ‘on the backlog’ indefinitely. Or playing whack a mole with problems instead of investigating root causes.
It’s a burnout/realism problem.
Very tempting in ops/QA for the business - and then when something breaks, or a customer gets angry because they’re getting blown off, blame the engineer/tech/QA person and fire them instead of fix the actual cause, which is unrealistic workloads, or bad process, or management prioritization failures, etc.