I think you're on the right track.

I used to code for Medical Devices. One of the rules of thumb we used for our level of comfort with a design (apart from formal Failure Analysis, etc...) was whether or not we'd be OK with having it used on one of our kids.

When you review someone's code (or mechanical design, or electronics) and you have to decide if you're OK with it being used to treat or diagnose your loved ones, it forces you to confront the immediate reality of the impact of your work. Suddenly that hack might not seem like such a good idea after all.

This is a really good point and it almost feels a little Kantian, so it seems to make sense to me. But the trouble is, when I speak of hacks, I don't mean things like defining rand() = 6. I mean things that seem really weird but after some thought, it seems to be correct. E.g. you had to add bunch of if cases to an algorithm due to some weird library requirement, and after hours of debugging the reason starts making sense and after hours of stress-testing, your algorithm produces the correct result. It's always possible you need to add more ifs and you're missing something OR the fact that you had to add ifs indicate your algorithm is not correct etc. Even after you feel comfortable a hack is good to go, that hack can still be a bug. Who knows? Engineering is all about the wisdom to decide whether something works or needs more work. It's truly amazing how stable most things are; but when you're familiar with the inner workings of a system, you're MUCH more self-conscious of possible catastrophic failures. Like, when you start reading about diseases in Wikipedia, you suddenly start checking yourself if you have those symptoms...

I think kludge is the more appropriate term here. A hack isn't necessarily a bad thing, but kludgey code is certainly not something I'd like sicked on my family.

Which is the basis of one of my arguments to anti-vaxxers: the doctors and scientists have decades of education and experience, and they take this vaccine themselves, and give it to their own children. That's the most reputable recommendation.

I don't think this is a very good argument. Anti-vaxxers care about their children very much, and therefore they DON'T vaccinate them, since they think it's bad for them. From their point of view, it's the doctors who are insane.

I think nielv's point is that the doctors who proscribe and the scientist who design these drugs have many years of professional education and generally at least a decade of experience in their fields. They have all of that domain knowledge about the vaccine, AND they care about their kids, AND they decide to vaccinate their children. They care just as much as the anti-vaxxer parents, but they also have the medical understanding to make a reasonable decision, while the anti-vaxxer's generally don't have medical or bio-engineering degrees and experience with the vaccines.

I´m pro-vaxx, but I feel the need to point out the flaw in this argument from an anti-vaxx perspective:

The same could be said about 1940s German "racial scientists", who had years of training convincing themselves about the genetic superiority of their people and the dangers coming from the "Jewish race".

I worked on the design of critical flight systems on the Boeing 757, and I'm particularly happy to fly on 757s.

Knowing how the airplanes are designed and built made me a much less anxious flyer.

Would you buy your family a ticket on a 777 Max?

The Boeing aircraft with recent notable safety issues is the 737 Max 8. Not any 777 variant.

https://en.wikipedia.org/wiki/Boeing_737_MAX

Just to be pedantic, the 757 is not a variant of the 777.

Yes.

That's just a more wordy way to say "ignorance is bliss".

But I totally agree, and I do not think you're wrong..

I work in medical devices and I am also always surprised how many "hacks" are in the system. We haven't had any field issues so I assume we are doing pretty well.

I guess most shiny things of any reasonable complexity look pretty dirty from the inside. There is just no way around it.

> I know all the dirty dirty hacks that are put into our systems

I would really hope that airplanes are a place where "dirty hacks" are unacceptable.

This doesn't mean they are 100% flawless, but any known potential problem areas should be well-documented and accounted for.

There's a couple of lines of code I wrote in a medical instrument that as far as I'm concerned are a dirty hack. Now, it's a documented dirty hack -- my boss called me into his office to laugh at the comment I wrote about it being the only way to accomplish what I needed due to the stupidity of the library I had to use -- but it's a dirty hack nonetheless.

The device has been performing admirably (as far as I know) for over 12 years in the field with no issues due to those few lines of code.

Hacks are everywhere in engineering. As long as the analysis behind it is rigorous and the hack is provably correct, I'm OK with it.

I realize I'm over-defining a silly term, but I'd consider that a "hack", not a dirty hack.

You understood exactly what was going on and were wholly confident it would be reliable. And more to the point, you wouldn't have counted it as a mark against the product's reliability.

That really depends on the hack. Maybe it's fragile because it is building based on a bug, and if the library changes, the code will have to be updated. Or perhaps it's there based on bad behavior of a chip and a hardware update could change the nature of the issue (say, it relies on a particular instruction that's generated by the particular compiler in use to happen just before the code in question).

A hack could be completely reliable (for the same hardware, library versions, and compiler), but still be a "dirty hack". And whether a hack is "dirty" is very subjective and, IMO, based more on how obvious the fix is (e.g. radians -> degrees -> function -> back to radians because the library documentation is wrong is less bad than a non-obvious hack like multiplying by 1 or something to avoid a compiler codegen bug because of a hardware bug).

I think this horse has been thoroughly beaten, so I'll leave it here.

While a well documented hack is OK, system, by design, shouldn't need or be built around hacks.MAX nose dive issue was a hack to counter the dive which proved fatal.

But maybe you shouldn't be using a "stupid" library in a medical device?

That's often times not an option. [Hypothetical] Just because I don't like the sensitivity of the airbag deployment sensor in the new Acura I'm designing doesn't mean I have the authority to switch it out. I can complain about it to management, but at the end of the day all I can do is modulate the signal going into to make it within industry-level safety specs.

Sure. I should just have taken 6 months off to write my own!

I mean...they did try to fix an inherent structural design flaw with software.

This is a common argument that sounds reasonable but is actually based on faulty logic.

Airbus pilots can't safely fly their jets at cruising speed without software (envelope protection, etc) assisting them. Air France 447 crashed, killing 228 people, when that software became disabled due to bad values from frozen sensors. The pilot flying thought the software would save him from stalling but that protection was disabled, so he crashed into the ocean.

So does that mean it's a bad idea to make flight software safety critical? Probably not.

It probably just means that safety critical software must be extremely good. MCAS v1 was not good software but if MCAS v2 is good software then it could might function safely for decades. And, if MCAS v1 had been good, it would have been lauded as a great solution.

Engineering is about trade offs and maybe Boeing made the wrong trade off here. Ideally, you would have as little safety critical software as possible. But the fundamental concept of software correcting for flight characteristics seems entirely sound.

But this software hack was added only to save a little amount of fuel (and money to retraint the pilots or redesign the airplane frame). Maybe it is better to have a slightly more expensive, but safer plane?

And what if a totally redesigned successor to the 737 started crashing due to a technical issue, or training issue?

Second System Syndrome is a well known engineering pitfall. If the only thing wrong with the 737 MAX is that the MCAS v1 software is bad, and the MCAS v2 software is good, then the 737 MAX should fly perfectly well for decades.

If you look as far back as the 60's, there was a lot of resistance from pilots with regard to unsafe airframes where various forms of trickery were employed to cover up problematic behavior. Check the D.P. Davies Interview by the Royal Aeronautics Society with regards to the 727. Even plastering over minor behavior near stall was a controversial move due to fears of pilot's at the time of starting down a slippery slope where more and more non-regulation compliant airframes were allowed to be certified because there would be some system X that would compensate for the aircraft's bad behavior. The fear being that eventually there would be so much automation between the pilot and the end behavior of the plane, that you might as well have a dog in the cockpit to bite the pilot should he try to mess with anything; and that should anything go wrong, the pilot would be helpless due to the plane only really being airworthy to his level of skill with the automation in place.

Boeing historically built planes flown by pilots. Every aspect of the planes behavior had a way for the pilot to control it. A Boeing plane would follow a pilot right out of the flight envelope, at least maintaining a 1:1 binding of pilot intent to plane output behavior.

Airbus makes planes flown by automation, directed by pilots, that should that automation fail, requires a significant investment of skill maintenance to know what not to do at that time. This makes common UI for the pilot easier to implement, but comes with discipline degradation through having a computer that will largely ignore your daft commands until it suddenly has no way to measure your daftness, leaving you with a plane with a hodgepodge of reliable automation to reason through about whether or not the plane will do something daft if you order it to.

History may show who won that argument, (Airbus does exist), but the fact does remain today that aircraft that one wants to certify as flying just like another aircraft (MAX flying like a 737) should actually do so. The MAX doesn't; the technological fix intended to make it so was not developed to a sufficient standard of rigor, or communicated to pilot clearly enough, to transparently account for that aerodynamic divergence.

The problem is multi-faceted, yes; but the statement that the MAX suffered from a fundamental design flaw is absolutely accurate.

The flaw exists aerodynamically, and in the fundamental engineering process through which it was certified.

[1]https://www.aerosociety.com/news/audio-the-d-p-davies-interv...

Interesting stuff, thanks.

But my understanding is that other jets have a similar pitch up characteristics and no one considers them to be fundamentally flawed. That the 737 MAX design creates a new problem vs the 737-NG does not necessarily mean it's fundamentally flawed.

I'd only consider it a fundamental flaw if MCAS can't actually be designed to compensate for the problem. An unsolvable problem due to bad design = fundamental flaw.

Otherwise having to stick a windshield on the front of an airplane could be considered a fundamental flaw. But it's not considered one because of very strong laminated materials compensating for the the problem. And yet it's still a huge potential risk. Windshields have cracked, broken, clouded up, etc.

The behavior held common with the other 737 variants is a tendency to pitch up with the application of power. All aircraft with underslung engines share this characteristic.

MAX, however, has additional problems where its flyability is adversely impacted when flying at high Angles of Attack when the engine nacelles (positioned higher and in front of the wing) creates extra lift in front of the center of mass of the aircraft. This creates divergences from the normal "control feel" of the older aircraft.

When at low power, and high AoA, (such as might be experienced on descent), sudden applications of power can cause pitch up, which can put the plane at an AoA that experiences this handling divergence. MCAS, in it's second form, was intended to induce a controlled mistrim to compensate for both it's original purpose (high speed, high AoA divergence from 737 NG handling), and a low speed, high AoA handling divergence.

It was being modified to handle the low speed case that removed an extra G-Load based cross check, and greatly increased the authority the MCAS system commanded, due to the larger deflections required to induce attitude changes in the low speed portions of the flight envelope.

The fundamental flaw I mention, is several fold.

Requirementswise:

A)The MAX had to be developed yesterday to allow Boeing to maintain dominance/market share in narrow body civil transport against the A320neo. (They needed it fast)

B) It had to be cheap. They needed minimum overhead cost to appease airlines, and comparable fuel efficiency to the A320neo. This meant no blank slate redesign. This locked them into the 737 type cert.

This meant (to an engineer):

C) It had to fly exactly like a 737... Without being one (They need it to be right).

In engineering, there is a common saying:

You can get it done cheap You can get it done fast. You can get [everything you want] done right).

Pick two.

For success, they needed all three, and delivering the third was not allowed the flexibility to intrude on either of the other points of the triad areas of process.

The only way this project could have ended was with a breakdown somewhere in the process. That breakdown was in communication and propagation of the significance of the aerodynamics change. That failure in communication was bundled in the "fast and cheap" directive. The "right" directive required the aerodynamics divergence, and the software control system reconfiguration to compensate for it. The cheap and fast also required that the software solution not be driven by a dual sensor system, as that wouldn't have been allowed through without simulator training by the FAA, as testified to by a whistleblower as reported in the Australian 60 minutes expose.

The whole thing is just a Greek tragedy in an engineering project's clothing. Hubris, greed, equivocation, catastrophe... It's all there.

Thanks for the reply. I agree that Boeing clearly made a huge mistake by rushing the process, and in doing so, did a bad job.

I'm still not yet aware of any reason that they won't be able to eventually make the MAX design safe and functional.

It's a very interesting example of engineering/business dynamics. I'll be happy whether the MAX flies successfully or gets totally scrapped, as long as no one else dies in a MAX from negligence.

It wasn't a structural flaw. The plane flies fine. It's a regulatory compliance flaw. It doesn't fly enough like the old one without the software.

And before anyone says "hurr durr it pitches up" (or something like that) the amount it pitches up when wide open at low speed is perfectly fine from a performance standpoint but it is not similar enough to the old plane to get away without retraining pilots, hence the software.

What is the structural flaw?

> To handle a longer fuselage and more passengers, Boeing added larger, more powerful engines, but that required it to reposition them to maintain ground clearance. As a result, the 737 can pitch up under certain circumstances. Software, known as the Maneuvering Characteristics Augmentation System, was added to counteract that tendency.

https://www.latimes.com/local/california/la-fi-boeing-max-de...

I'd call that a change in aerodynamic or flight characteristics as compared to earlier 737s rather than a structural flaw. That might seem a picky, semantic difference, but I think that, especially with aircraft, precision language is appropriate. The aircraft is not structurally flawed or at least no structural flaws have been revealed yet. It is perhaps a design flaw but, were there no earlier 737s to which it can be compared, it'd probably just be a flight characteristic.

It's a design flaw, because they're hacking an old design to have larger engines it was never designed for. If they did a clean-sheet new design, they'd never design it this way.

The airframe should be retired and they should make a new one. To push this, the FAA and other certifying bodies should treat the plane as an all-new plane with no commonality with previous 737 planes, requiring all new training for pilots and a complete, new certification process for the plane, just as if it had been a clean-sheet new design.