Back to Squawk list
  • 50

How the Boeing 737 Max Disaster Looks to a Software Developer

Design shortcuts meant to make a new plane seem like an old, familiar one are to blame ( Más...

Sort type: [Top] [Newest]

bob elmar 18
How the Boeing 737 Max Disaster Looks to a Software Developer
By Gregory Travis

Editor’s Picks
US National Transportation Safety Board Looks At Aviation Automation and Complacency
Parts of an engine of the ill-fated Lion Air flight JT 610 are recovered from the sea during search operations in the Java Sea, north of Karawang on November 3, 2018.
Indonesia Releases Preliminary Report on Lion Air Crash
Tesla Model S Autopilot
Tesla Autopilot Crash: Why We Should Worry About a Single Death

Photo of the crash site showing engine.
Photo: Jemal Countess/Getty Images
This is part of the wreckage of Ethiopian Airlines Flight ET302, a Boeing 737 Max airliner that crashed on 11 March in Bishoftu, Ethiopia, killing all 157 passengers and crew.
I have been a pilot for 30 years, a software developer for more than 40. I have written extensively about both aviation and software engineering. Now it’s time for me to write about both together.

The Boeing 737 Max has been in the news because of two crashes, practically back to back and involving brand new airplanes. In an industry that relies more than anything on the appearance of total control, total safety, these two crashes pose as close to an existential risk as you can get. Though airliner passenger death rates have fallen over the decades, that achievement is no reason for complacency.

The 737 first appeared in 1967, when I was 3 years old. Back then it was a smallish aircraft with smallish engines and relatively simple systems. Airlines (especially Southwest) loved it because of its simplicity, reliability, and flexibility. Not to mention the fact that it could be flown by a two-person cockpit crew—as opposed to the three or four of previous airliners—which made it a significant cost saver. Over the years, market and technological forces pushed the 737 into ever-larger versions with increasing electronic and mechanical complexity. This is not, by any means, unique to the 737. Airliners constitute enormous capital investments both for the industries that make them and the customers who buy them, and they all go through a similar growth process.

Most of those market and technical forces are on the side of economics, not safety. They work as allies to relentlessly drive down what the industry calls “seat-mile costs”—the cost of flying a seat from one point to another.

Much had to do with the engines themselves. The principle of Carnot efficiency dictates that the larger and hotter you can make any heat engine, the more efficient it becomes. That’s as true for jet engines as it is for chainsaw engines.

It’s as simple as that. The most effective way to make an engine use less fuel per unit of power produced is to make it larger. That’s why the Lycoming O-360 engine in my Cessna has pistons the size of dinner plates. That’s why marine diesel engines stand three stories tall. And that’s why Boeing wanted to put the huge CFM International LEAP engine in its latest version of the 737.

There was just one little problem: The original 737 had (by today’s standards) tiny little engines, which easily cleared the ground beneath the wings. As the 737 grew and was fitted with bigger engines, the clearance between the engines and the ground started to get a little…um, tight.

Illustration showing the Boeing 737 airliner.
By substituting a larger engine, Boeing changed the intrinsic aerodynamic nature of the 737 airliner.
Various hacks (as we would call them in the software industry) were developed. One of the most noticeable to the public was changing the shape of the engine intakes from circular to oval, the better to clear the ground.

With the 737 Max, the situation became critical. The engines on the original 737 had a fan diameter (that of the intake blades on the engine) of just 100 centimeters (40 inches); those planned for the 737 Max have 176 cm. That’s a centerline difference of well over 30 cm (a foot), and you couldn’t “ovalize” the intake enough to hang the new engines beneath the wing without scraping the ground.

The solution was to extend the engine up and well in front of the wing. However, doing so also meant that the centerline of the engine’s thrust changed. Now, when the pilots applied power to the engine, the aircraft would have a significant propensity to “pitch up,” or raise its nose.

The angle of attack is the angle between the wings and the airflow over the wings. Think of sticking your hand out of a car window on the highway. If your hand is level, you have a low angle of attack; if your hand is pitched up, you have a high angle of attack. When the angle of attack is great enough, the wing enters what’s called an aerodynamic stall. You can feel the same thing with your hand out the window: As you rotate your hand, your arm wants to move up like a wing more and more until you stall your hand, at which point your arm wants to flop down on the car door.

This propensity to pitch up with power application thereby increased the risk that the airplane could stall when the pilots “punched it” (as my son likes to say). It’s particularly likely to happen if the airplane is flying slowly.

Worse still, because the engine nacelles were so far in front of the wing and so large, a power increase will cause them to actually produce lift, particularly at high angles of attack. So the nacelles make a bad problem worse.

I’ll say it again: In the 737 Max, the engine nacelles themselves can, at high angles of attack, work as a wing and produce lift. And the lift they produce is well ahead of the wing’s center of lift, meaning the nacelles will cause the 737 Max at a high angle of attack to go to a higher angle of attack. This is aerodynamic malpractice of the worst kind.

Pitch changes with power changes are common in aircraft. Even my little Cessna pitches up a bit when power is applied. Pilots train for this problem and are used to it. Nevertheless, there are limits to what safety regulators will allow and to what pilots will put up with.

Pitch changes with increasing angle of attack, however, are quite another thing. An airplane approaching an aerodynamic stall cannot, under any circumstances, have a tendency to go further into the stall. This is called “dynamic instability,” and the only airplanes that exhibit that characteristic—fighter jets—are also fitted with ejection seats.

Everyone in the aviation community wants an airplane that flies as simply and as naturally as possible. That means that conditions should not change markedly, there should be no significant roll, no significant pitch change, no nothing when the pilot is adding power, lowering the flaps, or extending the landing gear.

The airframe, the hardware, should get it right the first time and not need a lot of added bells and whistles to fly predictably. This has been an aviation canon from the day the Wright brothers first flew at Kitty Hawk.

Apparently the 737 Max pitched up a bit too much for comfort on power application as well as at already-high angles of attack. It violated that most ancient of aviation canons and probably violated the certification criteria of the U.S. Federal Aviation Administration. But instead of going back to the drawing board and getting the airframe hardware right (more on that below), Boeing relied on something called the “Maneuvering Characteristics Augmentation System,” or MCAS.

Boeing’s solution to its hardware problem was software.

I will leave a discussion of the corporatization of the aviation lexicon for another article, but let’s just say another term might be the “Cheap way to prevent a stall when the pilots punch it,” or CWTPASWTPPI, system. Hmm. Perhaps MCAS is better, after all.

MCAS is certainly much less expensive than extensively modifying the airframe to accommodate the larger engines. Such an airframe modification would have meant things like longer landing gear (which might not then fit in the fuselage when retracted), more wing dihedral (upward bend), and so forth. All of those hardware changes would be horribly expensive.

“Everything about the design and manufacture of the Max was done to preserve the myth that ‘it’s just a 737.’ Recertifying it as a new aircraft would have taken years and millions of dollars. In fact, the pilot licensed to fly the 737 in 1967 is still licensed to fly all subsequent versions of the 737.”
—Feedback on an earlier draft of this article from a 737 pilot for a major airline
What’s worse, those changes could be extensive enough to require not only that the FAA recertify the 737 but that Boeing build an entirely new aircraft. Now we’re talking real money, both for the manufacturer as well as the manufacturer’s customers.

That’s because the major selling point of the 737 Max is that it is just a 737, and any pilot who has flown other 737s can fly a 737 Max without expensive training, without recertification, without another type of rating. Airlines—Southwest is a prominent example—tend to go for one “standard” airplane. They want to have one airplane that all their pilots can fly because that makes both pilots and airplanes fungible, maximizing flexibility and minimizing costs.

It all comes down to money, and in this case, MCAS was the way for both Boeing and its customers to keep the money flowing in the right direction. The necessity to insist that the 737 Max was no different in flying characteristics, no different in systems, from any other 737 was the key to the 737 Max’s fleet fungibility. That’s probably also the reason why the documentation about the MCAS system was kept on the down-low.

Put in a change with too much visibility, particularly a change to the aircraft’s operating handbook or to pilot training, and someone—probably a pilot—would have piped up and said, “Hey. This doesn’t look like a 737 anymore.” And then the money would flow the wrong way.

As I explained, you can do your own angle-of-attack experiments just by putting your hand out a car door window and rotating it. It turns out that sophisticated aircraft have what is essentially the mechanical equivalent of a hand out the window: the angle-of-attack sensor.

You may have noticed this sensor when boarding a plane. There are usually two of them, one on either side of the plane, and usually just below the pilot’s windows. Don’t confuse them with the pitot tubes (we’ll get to those later). The angle-of-attack sensors look like wind vanes, whereas the pitot tubes look like, well, tubes.

Angle-of-attack sensors look like wind vanes because that’s exactly what they are. They are mechanical hands designed to rotate in response to changes in that angle of attack.

The pitot tubes measure how much the air is “pressing” against the airplane, whereas the angle-of-attack sensors measure what direction that air is coming from. Because they measure air pressure, the pitot tubes are used to determine the aircraft’s speed through the air. The angle-of-attack sensors measure the aircraft’s direction relative to that air.

There are two sets of angle-of-attack sensors and two sets of pitot tubes, one set on either side of the fuselage. Normal usage is to have the set on the pilot’s side feed the instruments on the pilot’s side and the set on the copilot’s side feed the instruments on the copilot’s side. That gives a state of natural redundancy in instrumentation that can be easily cross-checked by either pilot. If the copilot thinks his airspeed indicator is acting up, he can look over to the pilot’s airspeed indicator and see if it agrees. If not, both pilot and copilot engage in a bit of triage to determine which instrument is profane and which is sacred.

Long ago there was a joke that in the future planes would fly themselves, and the only thing in the cockpit would be a pilot and a dog. The pilot’s job was to make the passengers comfortable that someone was up front. The dog’s job was to bite the pilot if he tried to touch anything.

On the 737, Boeing not only included the requisite redundancy in instrumentation and sensors, it also included redundant flight computers—one on the pilot’s side, the other on the copilot’s side. The flight computers do a lot of things, but their main job is to fly the plane when commanded to do so and to make sure the human pilots don’t do anything wrong when they’re flying it. The latter is called “envelope protection.”

Let’s just call it what it is: the bitey dog.

Let’s review what the MCAS does: It pushes the nose of the plane down when the system thinks the plane might exceed its angle-of-attack limits; it does so to avoid an aerodynamic stall. Boeing put MCAS into the 737 Max because the larger engines and their placement make a stall more likely in a 737 Max than in previous 737 models.

When MCAS senses that the angle of attack is too high, it commands the aircraft’s trim system (the system that makes the plane go up or down) to lower the nose. It also does something else: Indirectly, via something Boeing calls the “Elevator Feel Computer,” it pushes the pilot’s control columns (the things the pilots pull or push on to raise or lower the aircraft’s nose) downward.

In the 737 Max, like most modern airliners and most modern cars, everything is monitored by computer, if not directly controlled by computer. In many cases, there are no actual mechanical connections (cables, push tubes, hydraulic lines) between the pilot’s controls and the things on the wings, rudder, and so forth that actually make the plane move. And, even where there are mechanical connections, it’s up to the computer to determine if the pilots are engaged in good decision making (that’s the bitey dog again).

But it’s also important that the pilots get physical feedback about what is going on. In the old days, when cables connected the pilot’s controls to the flying surfaces, you had to pull up, hard, if the airplane was trimmed to descend. You had to push, hard, if the airplane was trimmed to ascend. With computer oversight there is a loss of natural sense in the controls. In the 737 Max, there is no real “natural feel.”

True, the 737 does employ redundant hydraulic systems, and those systems do link the pilot’s movement of the controls to the action of the ailerons and other parts of the airplane. But those hydraulic systems are powerful, and they do not give the pilot direct feedback from the aerodynamic forces that are acting on the ailerons. There is only an artificial feel, a feeling that the computer wants the pilots to feel. And sometimes, it doesn’t feel so great. 

When the flight computer trims the airplane to descend, because the MCAS system thinks it’s about to stall, a set of motors and jacks push the pilot’s control columns forward. It turns out that the Elevator Feel Computer can put a lot of force into that column—indeed, so much force that a human pilot can quickly become exhausted trying to pull the column back, trying to tell the computer that this really, really should not be happening.

Illustration showing the Boeing 737 anti-stall system.
The antistall system depended crucially on sensors that are installed on each side of the airliner—but the system consulted only the sensor on one side.
Indeed, not letting the pilot regain control by pulling back on the column was an explicit design decision. Because if the pilots could pull up the nose when MCAS said it should go down, why have MCAS at all?

MCAS is implemented in the flight management computer, even at times when the autopilot is turned off, when the pilots think they are flying the plane. In a fight between the flight management computer and human pilots over who is in charge, the computer will bite humans until they give up and (literally) die.

Finally, there’s the need to keep the very existence of the MCAS system on the hush-hush lest someone say, “Hey, this isn’t your father’s 737,” and bank accounts start to suffer.

The flight management computer is a computer. What that means is that it’s not full of aluminum bits, cables, fuel lines, or all the other accoutrements of aviation. It’s full of lines of code. And that’s where things get dangerous.

Those lines of code were no doubt created by people at the direction of managers. Neither such coders nor their managers are as in touch with the particular culture and mores of the aviation world as much as the people who are down on the factory floor, riveting wings on, designing control yokes, and fitting landing gears. Those people have decades of institutional memory about what has worked in the past and what has not worked. Software people do not.

In the 737 Max, only one of the flight management computers is active at a time—either the pilot’s computer or the copilot’s computer. And the active computer takes inputs only from the sensors on its own side of the aircraft.

When the two computers disagree, the solution for the humans in the cockpit is  to look across the control panel to see  what the other instruments are saying and then sort it out. In the Boeing system, the flight  management computer does not “look  across” at the other instruments. It  believes only the instruments on its side. It doesn’t go old-school. It’s modern. It’s software.

This means that if a particular angle-of-attack sensor goes haywire—which happens all the time in a machine that alternates from one extreme environment to another, vibrating and shaking all the way—the flight management computer just believes it.

It gets even worse. There are several other instruments that can be used to determine things like angle of attack, either directly or indirectly, such as the pitot tubes, the artificial horizons, etc. All of these things would be cross-checked by a human pilot to quickly diagnose a faulty angle-of-attack sensor.

In a pinch, a human pilot could just look out the windshield to confirm visually and directly that, no, the aircraft is not pitched up dangerously. That’s the ultimate check and should go directly to the pilot’s ultimate sovereignty. Unfortunately, the current implementation of MCAS denies that sovereignty. It denies the pilots the ability to respond to what’s before their own eyes.

Like someone with narcissistic personality disorder, MCAS gaslights the pilots. And it turns out badly for everyone. “Raise the nose, HAL.” “I’m sorry, Dave, I’m afraid I can’t do that.”

In the MCAS system, the flight management computer is blind to any other evidence that it is wrong, including what the pilot sees with his own eyes and what he does when he desperately tries to pull back on the robotic control columns that are biting him, and his passengers, to death.

In the old days, the FAA had armies of aviation engineers in its employ. Those FAA employees worked side by side with the airplane manufacturers to determine that an airplane was safe and could be certified as airworthy.

As airplanes became more complex and the gulf between what the FAA could pay and what an aircraft manufacturer could pay grew larger, more and more of those engineers migrated from the public to the private sector. Soon the FAA had no in-house ability to determine if a particular airplane’s design and manufacture were safe. So the FAA said to the airplane manufacturers, “Why don’t you just have your people tell us if your designs are safe?”

The airplane manufacturers said, “Sounds good to us.” The FAA said, “And say hi to Joe, we miss him.”

Thus was born the concept of the “Designated Engineering Representative,” or DER. DERs are people in the employ of the airplane manufacturers, the engine manufacturers, and the software developers who certify to the FAA that it’s all good.

Now this is not quite as sinister a conflict of interest as it sounds. It is in nobody’s interest that airplanes crash. The industry absolutely relies on the public trust, and every crash is an existential threat to the industry. No manufacturer is going to employ DERs that just pencil-whip the paperwork. On the other hand, though, after a long day and after the assurance of some software folks, they might just take their word that things will be okay.

It is astounding that no one who wrote the MCAS software for the 737 Max seems even to have raised the possibility of using multiple inputs, including the opposite angle-of-attack sensor, in the computer’s determination of an impending stall. As a lifetime member of the software development fraternity, I don’t know what toxic combination of inexperience, hubris, or lack of cultural understanding led to this mistake.

But I do know that it’s indicative of a much deeper problem. The people who wrote the code for the original MCAS system were obviously terribly far out of their league and did not know it. How can they implement a software fix, much less give us any comfort that the rest of the flight management software is reliable?


None of the above should have passed muster. None of the above should have passed the “OK” pencil of the most junior engineering staff, much less a DER.

That’s not a big strike. That’s a political, social, economic, and technical sin.

It just so happens that, during the timeframe between the first 737 Max crash and the most recent 737 crash, I’d had the occasion to upgrade and install a brand-new digital autopilot in my own aircraft. I own a 1979 Cessna 172, the most common aircraft in history, at least by production numbers. Its original certification also predates that of the 737’s by about a decade (1955 versus 1967).

My new autopilot consists of several very modern components, including redundant flight computers (dual Garmin G5s) and a sophisticated communication “bus” (a Controller Area Network bus) that lets all the various components talk to one another, irrespective of where they are located in my plane. A CAN bus derives from automotive “drive by wire” technology but is otherwise very similar in purpose and form to the various ARINC buses that connect the components in the 737 Max.

My autopilot also includes electric pitch trim. That means it can make the same types of configuration changes to my 172 that the flight computers and MCAS system make to the 737 Max. During the installation, after the first 737 Max crash, I remember remarking to a friend that it was not lost on me that I was potentially adding a hazard similar to the one that brought down the Lion Air crash.

Finally, my new autopilot also implements “envelope protection,” the envelope being the graph of the performance limitations of an aircraft. If my Cessna is not being flown by the autopilot, the system nonetheless constantly monitors the airplane to make sure that I am not about to stall it, roll it inverted, or a whole host of other things. Yes, it has its own “bitey dog” mode.

As you can see, the similarities between my US $20,000 autopilot and the multimillion-dollar autopilot in every 737 are direct, tangible, and relevant. What, then, are the differences?

For starters, the installation of my autopilot required paperwork in the form of a “Supplemental Type Certificate,” or STC. It means that the autopilot manufacturer and the FAA both agreed that my 1979 Cessna 172 with its (Garmin) autopilot was so significantly different from what the airplane was when it rolled off the assembly line that it was no longer the same Cessna 172. It was a different aircraft altogether.

In addition to now carrying a new (supplemental) aircraft-type certificate (and certification), my 172 required a very large amount of new paperwork to be carried in the plane, in the form of revisions and addenda to the aircraft operating manual. As you can guess, most of those addenda revolved around the autopilot system.

Of particular note in that documentation, which must be studied and understood by anyone who flies the plane, are various explanations of the autopilot system, including its command of the trim control system and its envelope protections.

There are instructions on how to detect when the system malfunctions and how to disable the system, immediately. Disabling the system means pulling the autopilot circuit breaker; instructions on how to do that are strewn throughout the documentation, repeatedly. Every pilot who flies my plane becomes intimately aware that it is not the same as any other 172.

This is a big difference between what pilots who want to fly my plane are told and what pilots stepping into a 737 Max are (or were) told.

Another difference is between the autopilots in my system and that in the 737 Max. All of the CAN bus–interconnected components constantly do the kind of instrument cross-check that human pilots do and that, apparently, the MCAS system in the 737 Max does not. For example, the autopilot itself has a self-contained attitude platform that checks the attitude information coming from the G5 flight computers. If there is a disagreement, the system simply goes off-line and alerts the pilot that she is now flying manually. It doesn’t point the airplane’s nose at the ground, thinking it’s about to stall.

Perhaps the biggest difference is in the amount of physical force it takes for the pilot to override the computers in the two planes. In my 172, there are still cables linking the controls to the flying surfaces. The computer has to press on the same things that I have to press on—and its strength is nowhere near as great as mine. So even if, say, the computer thought that my plane was about to stall when it wasn’t, I can easily overcome the computer.

In my Cessna, humans still win a battle of the wills every time. That used to be a design philosophy of every Boeing aircraft, as well, and one they used against their archrival Airbus, which had a different philosophy. But it seems that with the 737 Max, Boeing has changed philosophies about human/machine interaction as quietly as they’ve changed their aircraft operating manuals.

The 737 Max saga teaches us not only about the limits of technology and the risks of complexity, it teaches us about our real priorities. Today, safety doesn’t come first—money comes first, and safety’s only utility in that regard is in helping to keep the money coming. The problem is getting worse because our devices are increasingly dominated by something that’s all too easy to manipulate: software.

Hardware defects, whether they are engines placed in the wrong place on a plane or O-rings that turn brittle when cold, are notoriously hard to fix. And by hard, I mean expensive. Software defects, on the other hand, are easy and cheap to fix. All you need to do is post an update and push out a patch. What’s more, we’ve trained consumers to consider this normal, whether it’s an update to my desktop operating systems or the patches that get posted automatically to my Tesla while I sleep.

Back in the 1990s, I wrote an article comparing the relative complexity of the Pentium processors of that era, expressed as the number of transistors on the chip, to the complexity of the Windows operating system, expressed as the number of lines of code. I found that the complexity of the Pentium processors and the contemporaneous Windows operating system was roughly equal.

That was the time when early Pentiums were affected by what was known as the FDIV bug. It affected only a tiny fraction of Pentium users. Windows was also affected by similar defects, also affecting only fractions of its users.

But the effects on the companies were quite different. Where Windows addressed its small defects with periodic software updates, in 1994 Intel recalled the (slightly) defective processors. It cost the company $475 million—more than $800 million in today’s money.

I believe the relative ease—not to mention the lack of tangible cost—of software updates has created a cultural laziness within the software engineering community. Moreover, because more and more of the hardware that we create is monitored and controlled by software, that cultural laziness is now creeping into hardware engineering—like building airliners. Less thought is now given to getting a design correct and simple up front because it’s so easy to fix what you didn’t get right later.

Every time a software update gets pushed to my Tesla, to the Garmin flight computers in my Cessna, to my Nest thermostat, and to the TVs in my house, I’m reminded that none of those things were complete when they left the factory—because their builders realized they didn’t have to be complete. The job could be done at any time in the future with a software update.

“I’m a software developer turned network engineer and have written airliner avionics software in the past. It was interesting how many hoops we had to jump through to get an add-on board for the computer certified, while software certifications were nil (other than “cannot run on Windows,” “must be written in C++”). This was, admittedly, nearly 10 years ago, and I hope that things have changed since.”
—Anonymous, personal correspondence
Boeing is in the process of rolling out a set of software updates to the 737 Max flight control system, including MCAS. I don’t know, but I suspect that those updates will center on two things:

Having the software “cross-check” system indicators, just as a human pilot would. Meaning, if one angle-of-attack indicator says the plane’s about to stall, but the other one says it’s not so, at least hold off judgment about pushing the nose down into the dirt and maybe let a pilot or two know you’re getting conflicting signals.  
Backing off on the “shoot first, ask questions later” design philosophy—meaning, looking at multiple inputs.  
For the life of me, I do not know why those two basic aviation design considerations, bedrocks of a mind-set that has served the industry so well until now, were not part of the original MCAS design. And, when they were not, I do not know or understand what part of the DER process failed to catch the fundamental design defect.

But I suspect that it all has to do with the same thing that brought us from Boeing’s initial desire to put larger engines on the 737 and to avoid having to internalize the cost of those larger engines—in other words, to do what every child is taught is impossible: get a free lunch.

The emphasis on simplicity comes from the work of Charles Perrow, a sociologist at Yale University whose 1984 book, Normal Accidents: Living With High-Risk Technologies, tells it all in the very title. Perrow argues that system failure is a normal outcome in any system that is very complex and whose components are “tightly bound”—meaning that the behavior of one component immediately controls the behavior of another. Though such failures may seem to stem from one or another faulty part or practice, they must be seen as inherent in the system itself. They are “normal” failures.

Nowhere is this problem more acutely felt than in systems designed to augment or improve safety. Every increment, every increase in complexity, ultimately leads to decreasing rates of return and, finally, to negative returns. Trying to patch and then repatch such a system in an attempt to make it safer can end up making it less safe.

This is the root of the old engineering axiom “Keep it simple, stupid” (KISS) and its aviation-specific counterpart: “Simplify, then add lightness.”

The original FAA Eisenhower-era certification requirement was a testament to simplicity: Planes should not exhibit significant pitch changes with changes in engine power. That requirement was written when there was a direct connection between the controls in the pilot’s hands and the flying surfaces on the airplane. Because of that, the requirement—when written—rightly imposed a discipline of simplicity on the design of the airframe itself. Now software stands between man and machine, and no one seems to know exactly what is going on. Things have become too complex to understand.

I cannot get the parallels between the 737 Max and the space shuttle Challenger out of my head. The Challenger accident, another textbook case study in normal failure, came about not because people didn’t follow the rules but because they did. In the Challenger case, the rules said that they had to have prelaunch conferences to ascertain flight readiness. It didn’t say that a significant input to those conferences couldn’t be the political considerations of delaying a launch. The inputs were weighed, the process was followed, and a majority consensus was to launch. And seven people died.

In the 737 Max case, the rules were also followed. The rules said you couldn’t have a large pitch-up on power change and that an employee of the manufacturer, a DER, could sign off on whatever you came up with to prevent a pitch change on power change. The rules didn’t say that the DER couldn’t take the business considerations into the decision-making process. And 346 people are dead.

It is likely that MCAS, originally added in the spirit of increasing safety, has now killed more people than it could have ever saved. It doesn’t need to be “fixed” with more complexity, more software. It needs to be removed altogether.

An earlier version of this article was cited in EE Times.

Editor's note: This story was updated on 21 April to clarify that the MCAS pushes the airliner’s nose by means of the “Elevator Feel Computer.”

About the Author
Gregory Travis is a writer, a software executive, a pilot, and an aircraft owner. In 1977, at the age of 13, he wrote Note, one of the first social media platforms, and he has logged more than 2,000 hours of flying time, ranging from gliders to a Boeing 757 (as a full-motion simulator).
Chuck Lavazzi 5
Thanks for posting that for those of us on the wrong side of the paywall! I was in IT for 33 years, and while I don't know beans about aircraft design, I do know that trying to fix hardware flaws with software rarely works.
djames225 2
While we agree, Chuck, it is unfortunately their only option...short of tossing the whole design in the trash, not much else can be done other than adding MCAS limit switches on the jackscrew. and incorporating readings from the pilot tubes into the system
Chuck Lavazzi 1
It makes me very reluctant to board a 737 max again, though. The question is whether or not consumers will have any real choice in the matter.
djames225 1
Thks Bob, for posting the article. Stinks that it went back to "sign in"
Brad Littlejohn 27
This article can't be stressed enough. This guy sees exactly what the problem is, by both an IT perspective (which I also am) as well as a pilot's perspective (which I'm learning to be). This guy nails all 3 problems with the MAX, and not just with the operation of the aircraft. Pretty damning on the part of Boeing and the FAA.

If this guy gets sourced during any congressional hearing, some people's heads are going to roll.
Ken McIntyre 7
This article is soooo understandable. Wow.

Now on to the big question. How does Boeing and the FAA fix it? This is more than a software issue. It's the DC10 all over again.
Robert Cowling -2
A certain political party in this country is trying everything they can do to prove that government doesn't work. remember the 'government small enough to drown in a bathtub'?

Smaller government means way more corporate control over both government AND obviously, government functions.

So we have the FAA abdicating their inspection mandate in favor of trusting the very corporations to 'inspect' their products. And they spend MILLIONS to get INTO government, just to prove it doesn't work, and the rubes vote for them time and time again. It's astounding...

How does Boeing fix this? By FIXING IT, and having FAA and potentially NASA inspectors look at the fix, and the reason for the fix.
Dani Richard 0
From my perspective the fix is easy.
1. The full MCAS system as specified, which includes use of redundant sensors, AOA discrepancy indicator, and AOA indicators is part of the “minimum equipment list.” Which means if the discrepancy indicator is lit prior to flight the aircraft is grounded. While in flight an emergency is declared, the aircraft is grounded at the nearest suitable airport. (FAA will have to really think about this one).
2. All 737 MAX without the full MCAS system are to upgraded, at Boeing expense..
3. Ferry flights for non full MCAS aircraft will be conduced only by Boeing Test Pilots.
4. All 737 MAX pilots will be trained in detect MCAS failure and be tested in diagnosing the difference of MCAS failure and “trim runaway” failure while in a departure attitude.
From the internet expert's perspective, everything is easy.
Dani Richard 4
I agree that from the internet everything is easy.
In addition to being a Computer Scientist, I was cross trained into Systems Engineering and worked as one for 7 years.
My last three years of employment were testing the Flight Software the Space Launch System. Rockets have two salient aerodynamics problems: 1. They are aerodynamically unstable. 2. The airframe is so un-stiff it has resonance that vectoring the rocket motors will excite those frequencies.As advance airplanes are build, I expect see both problems in future aircraft. For rockets, “fly by wire” is essential. In looking up Gregory Travis only one has a ATP, Multi and type ratings, and A&P liencse (CIF rating has expired). I only have a Private ticket with Instrument and a Ground Instructor: Advanced and Instrument. The key experience I have is testing Man-Rated Flight Software, reading requirements, inventing Test Procedures, run simulations with anomalies and falilures and evaluate the simulation data to conform (or report an error) oft the written requirements. My person opinion is no 737 MAX should every take-off without a fully functioning MCAS system. Past experience shows they crash. So far a 737 MAX with a full functioning MCAS system is yet to crash. I would love review the requirements of MACS and write “Test Procedures” to see if it really works as specified. Such a test program review would easily take a dozen Test and Evaluation people working a minimum of 6 months to a year to qualify the MCAS.
SHHH!!!! keep that on the down low! You don't want to undermine JMARTINSON's credibility with this and show that he's wrong. ;)
Read the article again. His bona fides are clearly listed, especially since the IEEE is an international organization of engineers, in which their works are peer-reviewed and published in peer-reviewed journals.

Additionally, since his name is on the article, you can also look him up in the FAA database for his pilot credentials. Again, his qualifications clearly exceed yours.
Oh, please, it's an obvious editorial.

1. A single author

2. "The views expressed here are solely those of the author and do not represent positions of IEEE Spectrum or the IEEE

3. "how this looks" in the title

3. Zero relevant references or citations

Peer reviewed scientific paper? Give me a break.

So do you really read a statement like "The most effective way to make an engine use less fuel  per unit of power produced is to make it larger" and not question it? At all? Contrary to basic common sense with no explanation whatsoever... but you just accept it as fact and move on? Gasoline, diesel, jet, it doesn't matter, bigger is more efficient? Doesn't it at least make you wonder why we aren't driving around in 2019 Honda Accords with 502 cubic inch big blocks even a little? Because bigger is more efficient, right? Help my un-credentialed brain understand. Even if he's right, he's doing it wrong.

This should make you question what he claims about Carnot Efficiency, but nope. He's a 172 pilot.

I don't care if his credentials exceed mine, I care if they are relevant and give him enough insight or experience to be an expert. He is claiming to be an expert in everything from aerodynamics to thermal dynamics to airliner manufacturing because he is a software developer, 172 pilot, and flew a 757 simulator. And oh, IEEE member in good standing.

If you call this bona fide, your standards are too low.
You still don't get it.

1. Single author has nothing to do with it.

2. I never said that his views represent those of the IEEE.

3. From a SOFTWARE DEVELOPERS' perspective, this is how it looks. FROM A PILOT'S PERSPECTIVE, he's reserving judgment. You don't get the stances he's taking, but that's on your own naivety.

4. He's taking his knowledge of flying, combining that with his knowledge of engineering due to his IT/Software Development/Engineering background, and combining the two. I don't see you doing the same exact thing.

Again, his creds are clearly well shown, not only in the IT world, but also in the aviation world. Again, FAA records are publicly accessible; feel free to look them up.

And I didn't say that this article was peer reviewed; I said that those with the IEEE have peer reviewed papers published.

But please don't let your ignorance of the IT world get in the way of a good circle jerk.
My ignorance of the IT world, I wish.

If stupid could fly, you'd be a jet.
djames225 2
So you are a software engineer?
This, coming from someone who believes that error-prone software with no crosscheck can fix a hardware design problem.

Pot. Kettle. BLACK. Thank you for proving my point about your lack of knowledge in the IT world.
Hopefully by the time the hearings roll around he figures out the 737 isn't fly by wire, MCAS isn't active with autopilot on, and MCAS doesn't move the control column... and large pistons don't increase efficiency, and so on and so forth. Next.

It's really starting to look like the only way to find a good article is to stop reading at the end of the article (and call it good).
FedExCargoPilot 11
Classic Engineering 101 mistakes, picking a solution without defining the problem. In addition to not listening to stakeholders. excellent article
Paul Kaiser 11
This guy gets it. My colleagues refer to the root of the problem as Management By Spreadsheet. There is so much pressure for companies to be profitable, that sound engineering processes eventually get compromised. A recent cartoon I happened upon recently showed several people sitting around a campfire, with a storyteller saying something like “Yes, the earth was destroyed, but for a brief moment in time, we created a tremendous amount of shareholder value. “. As an industrial Controls Systems software engineer for 30 years (now a full time Commercial pilot), i worry that software designs in aviation could become insufficiently fault-tolerant. The Human Factors requirements of how automation is monitored and utilized by pilots cannot be over emphasized. I’ve witnessed how major companies try to improve their bottom lines by eliminating engineering and research staff and simply outsource those tasks. This more often than not results in compromised design decisions, followed by a “we’ll fix it with software” mentality. Props to the author of this article, it’s a must-read for anyone interested in understanding how Boeing got in this mess.
scott8733 10
Might be the best article I've seen on the matter. Easy for both the layman and expert to understand. His parallel between the Challenger disaster and the Max crashes were remarkable.
Jayden Hakunti 8
Very well written comprehensive article. I would summarize the main points with excerpts for those who would like the main points:



Aeroknut -1
“Known for their propensity to fail”... I have been unable to find a single pilot (a survey of over a million flight hours and hundreds of thousands of hours of flight time in the 737) who have ever experienced an AOA FAILURE. Some have experienced (over 20 years ago) an AOA anomaly on the ground prior to take off roll due to strong tail winds, but never in flight.
Aeroknut 1
Typo...sorry over a million flight hours and over a thousand equivalent years of flight time in the 737
You are supposed to ignore that sort of thing, because the article if full of it.

You are swimming against the current called internet outrage. You are going the right direction and doing the right thing, but you will still drown.
Mike Lynn 4
I'm not a pilot, just a lowly passenger suffering with normal seat pitch issues or clogged toilets. Those minor inconveniences still have always left me with the knowledge that I would arrive safely. No more!

I read the article and it highlighted for me, how the culture of building a plane and then having it's safety elements verified by an independent party (the FAA) have been compromised. I believe Mr. Travis has shown how we have reached a serious cross roads where we need to look more closely at human/computer interaction - as a human pilot when do we take back control? Think Air France A-330 accident over the Atlantic a few years back.

We also should expect more out of the airframe integrators. Boeing was lazy and wanted to push one more 737 variant out the door without having to design and build a totally new plane and the economics for doing that are highlighted in the article very well. At a minimum, Boeing should have boldly highlighted to the pilot community who would be flying the MAX, the differences due to the center of gravity changes, the bigger engines and how the AOA, pitch and stall characteristics would be different from the older models. This was pure negligence on Boeing part.

Let's hope the new "software patch" and augmented pilot training will do the trick. Even with the fixes it will still be a few years before I fly on a MAX until it is proven the patches work. This should be a wake up call for the whole aircraft industry.
Excellent article. As a Boeing stockholder, I hope that the company's management takes the author's analysis seriously.
Francis smith 6
It looks to me that Boeing has made a mistake in delaying a new single aisle design, instead trying to wring more money out of the 737 design, particularly with its short landing gear.
siriusloon 2
Boeing is in business to sell aircraft, not just to design them. They manufacture what their customers want and lots of customers want more 737s because they already have 737s and want commonality in their fleet. Boeing doesn't start work on a new aircraft unless they're damned sure that its customers want it. If they had told all the customers for those thousands of NG and MAX jets that they refused to build them and they had to buy a brand new aircraft, a significant number of those customers would have booked meetings in Toulouse.

Boeing's done a lot of things wrong in recent years, but building what their paying customers want isn't one of them.
An excellent and easy to understand article that explains the issue and why it is so difficult to recover. Is anybody aware of how it is determined which flight computer controls the aircraft. Article states that it is either the pilot's side or the co pilot side with no cross checking by the computers
I won't say that it is automatically set, but is rather arbitrarily decided, by who is PIC at the time, which may come down to rank between Captain and FO. If the Captain gives the plane to the FO, then the FO is PIC, and his side would control, without any safeguards for the cross check. Opposite applies for if the Captain is the PIC.

So it all depends on who is PIC of the aircraft at the time, as their control would determine which FMC controls the aircraft.
Thanks Brad. So for the ET flight it might have been that is the PF (Captain I believe) had passed control to the FO (PNF) and the FO's AOA sensor was working properly all might have been good. This is an unlikely scenario as the FO had very low total time and with control problems it is highly unlikely that the Captain would pass control, but it might just have been what was needed. This is consistent with accidents rarely having a single cause but more often a string of events. All very interesting.
s2v8377 3
A very interesting and well written article on the 737 MAX.
Ellis Stuart 3
I will NOT, be flying on a MAX aircraft!
Dani Richard 3
As a Computer Scientist with some years of Systems Engineering experience and manned space flight software test I see:
1. The software requirement MCAS specified the system with two AOA sensors and the software comformed to requirements.
2. One AOA sensor is a “degraded mode” of the MCAS software.
3. It as a “managment decision” to sell the specified, full MCAS systems as an “option” instead of “minimum required equipment.”
4. There is management memo somewhere to sell full specified MACS system as an option. That memo killed people.
Rico van Dijk 3
Finally an article I can pass on to my non-aviation friends to explain what’s going on! Brilliant!
George Cottay 4
Brad already said it, but just to repeat the article is longish but well worth reading.
Dave Steele 2
Have to sign in to read.
Kevin Gent 2
They should have never stopped producing 757, it would meet the requirement with the newer engines.
skylab72 2
I to have lived at the intersection of aviation and "computer science" since 1969. Resume includes Sisk Aviation, McDonnell, McDonnell-Douglas, Lockheed, Lockheed Electronics, and NASA. Favorite quote from this article is, "The problem is getting worse because our devices are increasingly dominated by something that’s all too easy to manipulate: software."
lynx318 1
Wow the article is TL:DR in some respects, definitely an IT writer.
In a nutshell, bigger engines fitted > too close too ground > raise engines > alters angle of attack drastically from original 737 design > patch it with MCAS > we know what happened next.
Instead of raising engines, why not just lower ground, I.E. lengthen landing gear or am I missing something?
Ivan Blakely 1
Very interesting article.
My specialty was telecommunications engineering, morphing into "IT" through the computer revolution and convergence. Interested in aviation, but not an insider so defer to those who are.

One aspect I have not see anywhere is the systems engineering methodologies applied by Boeing.
MCAS is a software solution, and "Agile" is very popular these days in IT where the commercial imperatives are to release software early and often, effectively relying on customers to test it for you.
I don't care that much if my phone tells me I have 21 apps requiring updates, but I trust Boeing, Airbus and the others are not "Agile"...
Ivan Blakely 1
can I read it without being an IEEE paid up member?
Ivan Blakely 1
ignore - found the "register without paying" option.
John D 1
Seems to be a paywall up now on this article. I read it last week. Great feedback here.
bob elmar 1
Can somebody copy and paste the article here? I am not a member
ToddBaldwin3 -1
That's interesting. We were all able to ready the article earlier without being a member.
Mike Lynn 1
I am not a member either but went to this link where you can set up a free membership in 2 minutes
bob elmar -4
Really? Is that why others are also asking about the article? Why dont you just share how you did rather than being an arrogant a-hole?
somebody is definitely an arrogant a-hole, but it's not who you think.
Steve Cutchen 1
Earlier version of the article, not paywalled:
hal pushpak 0
I wish the author had included the trouble with the trim kill-switch(es) and why that wasn't enough to regain control over the trim.
Dani Richard 2
From other reports, it seems the trim motor with MCAS can trim the aircraft much faster than a pilot can trim manually. Most large airplane have ‘electric trim”. It is real handy in IFR conditions. What I don’t know for sure is the speed of the trim motor with MCAS engaged and the normal electric trim. Does disconnecting MCAS also kill electric trim? Or had they disconnected electric trim, thinking of “trim runaway”? (That would have been my first reaction.) With no indication that MCAS was running in “degraded mode” with only one AOA, and absences of an AOA indicator showing bad values, the time to diagnose and recover trim was limited. Please note none of Full MCAS systems, a 737 Max option, crashed. Only those MCAS systems that were running in degraded mode crashed.
Aeroknut 1
He can’t because he has no understanding of it. The “pilot” barely has enough flight time to become an ATP and doesn’t even appear to have any type ratings.
He didn't include it because it doesn't fit his this-is-all-Boeings-fault narrative. The airplane was going way too fast is why. The throttles were set at 84% for take off and that's where they stayed.
Aeroknut 0
Looks like a bit of self promotion to me.
Frank Zumbo -2
Has anyone ask if these planes really need the MCAS system? It seems that there are a lot aircraft out there flying every day and doing so without problems!
ToddBaldwin3 7
I think you should go back and re-read the article. From my understanding, the -MAX has an inherent instability that was solved with a software fix. Seems to me like a "workaround," which is generally not a good idea.
Frank definitely needs to re-read the article, as it does explain it, but the actual issue with the -MAX is that the engines are too big for the wing. Because of that and at the speeds the aircraft flies at, the engines themselves can produce lift, which in turn increases the angle-of-attack of the aircraft. That's where MCAS was to come in - to prevent too much of an angle of attack

In short, they are trying to use software to fix a physical design flaw of the aircraft, and it cost them lives, and now they are trying to fix that problem with MORE software. big mistake.
djames225 3
While I agree with your last sentences, Brad, unfortunately that is their only alternative...short, of course, to tossing the whole thing in the can and starting over.
True. They made that bed of roses and are now having to lie in it and sleep with the thorns. And obviously, the best way would have been to redesign this altogether. And in playing Devil's advocate, they really didn't have a choice on this without ceding all sales from any competition on this to Airbus.

However, they were being too frugal on this without a bit more thought into this than what they should have had. I mean, if an IEEE certified engineer could have told them that this was a problem, then what the hell were Boeing's TEAMS of engineers thinking? Or were they?
skylab72 0
The "Not invented here" syndrome is powerful in Boeing. The basic 737 design was a "quickie" answer to the DC-9. They simply scaled down an airframe to be built of parts already in production for the 707-720 and bolted on short legs and engines of adequate size. The error was in not recognizing when they gained control of the 717 platform that it was technically was far better suited to scaling up for the "short to medium range market" than the underwing twin already stretched to its aerodynamic limits. Boeing is good at puffing up a fuselage. The basic layout of the 717 is already a world standard in that class. Aft mounded twin engines on a low fuselage can take whatever engine is needed. Certification? It is just a variation on a 717...
lynx318 1
If Boeing loses all MAX sales, they're going to have to scrap it.
They've already lost a LOT on this, and their stock has taken a hit. Coincidentally, my employer made drastic changes to their 401k program, in which I opted to take my entire portfolio and invest it into different IRAs and portfolios, which was a bummer because one of the portfolios in that 401k had stock in Alaska Airlines, Lockheed Martin, and Boeing.

It appears I made the right call in doing that because in the way I had it invested, I would have lost a good mid 5 figures from Boeing's stock price drop since ETH610.
777 captain also certified on 737s
Software developer 172 pilot

Keep hitting that down arrow if it makes you feel better.
djames225 3
And your point is? MOST of the issue with the MAX8/9 is the stupidity that went into A: designing a jet that would be known to create additional uplift/easier to stall then B: installing utterly STUPID software into it that RELIES on only 1 sensor. Redundancy, Redundancy, Redundancy! AND THEN HAVING the utter audacity to turn off and "optionize" the system that would warn of AoA disagreement..look at your 737NG...AoA disagreement lights THAT WORK!
Yes a software developer THAT MAKES SENSE..I couldn't care less if he only flew gliders, he has basic working knowledge of aerodynamic lift AND proper software coding!
There you are! What took so long? I was starting to worry.

I'm not saying anything other than maybe the iee guy is wrong and the max is actually not "inherently unstable" like he claims it is. And if he is wrong, it's not unreasonable to wonder if he might be wrong about something else. The alternative is to assume he's perfect except for just that one thing.

If it turns out the airplane is not inherently unstable, you can still hate Boeing you know.

Anyway, your last sentence is my point. You'll accept any experience, training, or education as authoritative as long as it aligns with your position, and you'll dismiss them just as easily when they don't (or change the subject, attack the messenger, type IN ALL CAPS, click the down arrow, or whatever). You said it yourself, you could care being incapable of changing your mind is a good thing. It's not good, it's irrational. As a coder you should know that. It's also confirmation bias at it's best.
djames225 2
It is pointless to even try any conversation with you. A pilot must understand the basic fundamentals of lift of an aircraft and what can cause additional lift and when you do and do not want it. I am quite capable of changing my mind when something seems out of the ordinary, but you keep dwelling on the fact how he's only a Cessna 172 pilot (So he knows the fundamentals of aircraft lift), and a software coder. He knows lift and he knows proper software coding, and the caps were there to try and drive a point home. Obviously that failed and you still wish to argue which I am done with.

P.S.If the aircraft wasn't "inherently unstable", why did Boeing add the MCAS?
skylab72 0
OK rw, I'll take a crack at it. You ask, "If the aircraft wasn't 'inherently unstable', why did Boeing add the MCAS?" JMart's link explains it below, but it rambles a bit. So let me start with the simplest true statement of that 'why', then add some explanatory thoughts. >Boeing added MCAS to the 737Max Series flight control systems to allow them to 'feel' more like legacy 737 airframes in all flight regimes.< "Inherently instability" was not the issue. The phrase "pitch stability" is engineer-speak referring to rates of change, in the rate of change, in the pitch attitude of the aircraft. Two aircraft can easily be well matched in overall stability, and yet "feel" completely different due to small differences in pitch stability in various flight regimes. Boeing seems to assert MCAS was written to better match the feel of a 737Max to a 737-400.
Did that help?
djames225 1
You can try and place that thot with someone else "to make it feel like a 737-400". The MAX is not equal to stability of a 737-400. even with the addition of MCAS. But thanks for adding 2 cents
skylab72 0
Show me the graphs hotshot. You are blaming the hardware for a software issue that collided with a couple of dumbshit marketing decisions. Yes, the airframe issues "could have been avoided" but do you really expect Boeing to promote the 717 to be their primer short-to-medium range type?
He isn't blaming the hardware for the software issue. The hardware issue is easily apparent; he's blaming THE USE OF SOFTWARE TO RESOLVE THE HARDWARE PROBLEM. That's been the problem the entire time The use of compensating for the design flaw with software is like trying to use a bandaid or gauze on the 5th chamber of your heart to stop it from being used, despite the fact being that you have a 5th chamber in your heart when we are supposed to only have four.

On the B38M and B39M, the engines are too big, so they were moved, but that combined with the location of the landing gear can contribute to a sharper AoA. design problem there. MCAS is the bandaid, where a redesign of the fuselage of the B38M and B39M are the solution.

Also, note how the MAX 10 gets a pass here, because of the longer/larger fuselage, allotting for the repositioning of the landing gear and engines.

djames225 2
Shh Brad...somehow, I dont think some folks realize how much influence an engine nacell, or its location, has on lift/
skylab72 0
See Above
djames225 1
I am blaming hardware that does not fly properly without software patches, hotshot. If this was just "software that collided with dumbshit marketing decisions" WTH is Boeing going all out, to the tune of over $1 billion and counting?
And what, or better still why, would you be bringing up the old 717?
skylab72 0
What I was trying to say when I got excessively succinct (apparently)...
{forgive the cut&paste for ease of reference only} You said, "stupidity that went into A: designing a jet that would be known to create additional uplift/easier to stall then B: installing utterly STUPID software into it that RELIES on only 1 sensor. Redundancy, Redundancy, Redundancy! AND THEN HAVING the utter audacity to turn off and "optionize" the system that would warn of AoA disagreement..look at your 737NG...AoA disagreement lights THAT WORK!"

>>> So point A is weak, so oversimplified as to potentially confuse the uninitiated and demand discount from the expert. Also a bit naive, I suspect you would be shocked how many post-WW-II aircraft have designed in "handling quirks". Some of them more severe than the 737Max. Some, so severe as to cause the withdrawal of the aircraft from service. But my main objection to point A is that insisting that the 737Max is "unstable" (common usage of the term, like maybe "been known to wobble a bit") is just not true. I insist overall the whole 737 lineup has consistent enough airframe stability, end to end, that the part95 certification of 737Max does not seem unreasonable (don't get excited, I am not dismissing the procedural controversy, I am just saying I believe a competent team could have accomplished that without the debacle Boeing is currently bathing in.) Worst insisting on an overblown hardware issue weakens your argument by shifting focus from the bone-headed management decisions.

Moreover, while I might reword your point B, I like most commenters on this thread heartily agree. I (and I assume we) also find it's key points quite unsettling. I would argue however that MCAS does not "rely on only one sensor" it is simply capable of not crashing (software sense) when it finds itself missing that input. MCAS "knows" about redundant AOA sensors and how to use them and set off alarms when they disagree. It was a "dumbshit marketing decision" that made the second sensor an "option"... Your point exactly. If it were up to me I would make a third AOA sensor on a deiced stalk out front of the wing somewhere standard. But I'm just a software geek that likes lots of inputs.

Boeing took control of the DC-9<>MD-xx<>717 intellectual property in the early nineties. As a short to medium range platform, it was the standard. For decades the aft fuselage mounted twin-engined T-tail has dominated the class, with too many imitators to count. The 737 has, in contrast, been a hodge-podge quickie design to optimize schedules and minimize construction costs. From its beginning as a hacked up 707 with a scaled-down wing, sporting shortie landing gear for easy baggage loading, and adequate engines mounted with no strut it has trailed a snowstorm of fixes and advisories. Had Boeing not suffered from the all too common NIH (not invented here) syndrome, it might (should) have begun upgrading the 717 platform with modern engines, enhanced super-critical wing and fatter fuselage to create a Real class killer. {As opposed to a passenger killer.}

That is why I would bring up the old 717.
Well of course it's pointless when the basis of your argument is a 172 pilot having a better understanding of a 737 than a 737 pilot does.

Q: If the aircraft wasn't "inherently unstable", why did Boeing add the MCAS?
A: I'm just some idiot with an internet connection, so heck if I know. Maybe he does:
lynx318 2
BINGO, you don't know!
Click the link there, partner.
lynx318 2
Who is he when he is someone, MCAS is not retro installed to earlier std size engine 737's as it is not needed. It is nothing more than an instability patch.
See Boeing's own explanation of it.
A-HA! So you don't know!

enhance pitch stability so that it feels and flies like other 737s isn't exactly the same thing as inherently unstable (like it's a B2 or something).

You guys are kind of mean with your down votes thing. Nobody likes me!
lynx318 1
That's just it, I do know, what an idiotic statement. Not 'LIKE' other 737's, but as you would expect ANY correctly engineered plane too fly, without unnecessary computer assistance. B2 doesn't count, a flying wing is always going to be unstable and is beyond human reflexes to control. Stop talking through your hat and the downvoting will stop.
skylab72 -1
lynx, dude it is really bad form to bag someone claiming they made an "idiotic statement" then follow it immediately with an assertion both idiotic and naive beyond belief. Really? >>>you would expect ANY correctly engineered plane too fly, without unnecessary computer assistance?<<<

I will grant there are a few airframes designed to be dynamically stable AND aerodynamically default(0 control input) to a minimum rate of decent, but they are far from the majority.

EVERYTHING in engineering is a tradeoff, and by assuming design behavior you do not understand is due to incorrect engineering is to assume you know and understand all the design requirements, which clearly is impossible.

Take yourself less seriously and read with an open mind. you might learn something.
lynx318 2
Aircraft have been around far longer than computers, including the design of, yet they were built and flew damn well. The keyword I used was 'unnecessary', not none at all. Try reading the comments correctly please.
skylab72 0
That, my good man, is exactly the word I object to (see rw comment above). Let me be clear. I agree with the basic attitude you both seem to have about the need to design in the characteristics needed in a given aircraft, rather than attempting to "patch" a flawed design by adding stress and behavioral oddities to the flight control system. My objection was to characterizing the failure as an engineering failure. I agree the engineering team 'could' have produced a design that did not have the life-threatening flaws we are discussing. I do not agree that the reason they did not, is rooted in the engineering discipline. I would argue the failure was the result of the way the team was managed.
lynx318 2
They rushed the design through to try and pry back sales against the Airbus A320 Neo, It was a failure in management yes but in no way can the engineers be forgiven for signing off on a design that created a major handling issue.
djames225 1 really are ignorant "EVERYTHING in engineering is a tradeoff" REALLY?? If I worked with that kind of assumption, my butt would be out on the street!
And YES..I, not the friggen autopilot, would expect ANY correctly engineered plane to fly without unnecessary computer assistance!
skylab72 0
Sorry, but we are still miscommunicating, rw. I appreciate your preference for aerodynamically coherent airframe design! Deliberate instability is not what I am trying to espouse. YES, a "correctly engineered plane" >should< fly in a dynamically stable manner with a minimum of control inputs from ANY source. Where I stumble is the phrase "unnecessary computer assistance". The devil is in the details and one could hide a multitude of sins in that phrase. What is "necessary"? Any? All or nothing is naive. In the real world a large number of aircraft ever since the advent of mercury bubble & gyro based, tube amped auto-pilots have pushed this boundary between man and machine, usually at the cost of lives. Succinctly as I can state, we must not only machine-rate the men who fly them, we must man-rate the machines we fly. That became our mantra for the Apollo program. It is still true.

Oh and insult all you want, but if you do not understand that every decision made in an engineering context involves trade-offs, you sir, are NOT an engineer.
djames225 1
I am not insulting, merely making a point..EVERY decision made in an engineering context does NOT require trade-offs. If you are an engineer and have that kind of attitude towards it...sorry.
And unnecessary means just that...if I was having an issue flying the craft and the computer could lend a hand, great...but if I'm flying a craft, not the autopilot, having no issues other than slight turbulence or a first officer who wore too much aftershave etc, I do not want a computer dictating, and carrying out, the moves for me.
On the MAX, if it encountered an overly rambunctious upwards nose trajectory, due to their placing the engines where they did, I would expect a warning about potential stall followed by a bit of stick shaking. Only at the point where the nose up attitude was thinking of starting to go critical, AND 3 sensors confirmed it, then "necessary" action by the computer would be welcomed and warranted.
skylab72 0
So " really are ignorant" is not an insult???
skylab72 -1
EVERY decision made in an engineering context does NOT require trade-offs. YES, as far as that goes...
EVERY decision made in an engineering context IS A trade-off. Big difference!

