Boeing 737 Max: Software patches does not solve the root problem

Last week, a Boeing 737 series “MAX 8” airliner, operated by Ethiopian Airlines, crashed only minutes after takeoff, killing all 157 passengers and crew aboard. This incident, following a similar crash in October by Lion Air, has resulted in the entire production line of 376 aircraft being grounded by the US and every airline in the world that operates them.

If this had been any other type of plane, a major crash of this nature — as they have been in the past — would’ve had the usual scrutiny by our aircraft regulation authorities, the FAA and the NTSB, as well as any number of airlines and foreign regulatory equivalents. Rarely does a crash like this result in the grounding of an entire species of aircraft, long-term.


The 737 Max is a modern, recently released derivative of a highly successful airframe, the 737, that has been flying since the late 1960s. Very few aircraft have had such a successful and safe operational record as this design, which has remained relatively unchanged for about 50 years. Over 10,000 737s in the past five decades have been built, making it the most prolific jet airliner design in existence. Only the Airbus A320, with over 8,000 in service, comes close.

With the introduction of the “Next Generation” versions starting in the late 1990s, the airframe, under the “Classic” product line over the past 20 years, has had a few important modernization efforts in order to improve efficiency, such as with avionics and winglets, as well as a few modest power plant improvements and refits and a denser passenger seat layout.

But the basic design and performance characteristics of the 737 have — until May 2017, with the 737 MAX on Malindo Air, and following suit on other large carriers in the past two years — remained largely the same.


Within months, Boeing scrambled to one-up Airbus with a high-efficiency variant of its own.Seeking not to design a completely new airframe for the purposes of competing with this plane, for economic reasons, it chose the proven 737 design instead. 

However, the 737 is a much older airframe design than the A320, so a lot more technical rejiggering was required to accommodate a newer, larger power plant. 

The larger CFM International LEAP-1B turbofans would have required much taller main landing gear to handle the increased ground clearance. Since this was not a practical solution, the engines were mounted higher and more forward than in previous 737 iterations. 

However, this solution presented a different problem: The aircraft no longer had sufficiently stable handling at a higher angle of attack (AoA) to be certified for flight by the FAA. Therefore, Boeing developed a system, called the Maneuvering Characteristics Augmentation System (MCAS), to compensate for the aircraft’s handling deficiencies.

Computer systems used to compensate for unstable airframes aren’t new. In fact, most modern military jet fighter aircraft are inherently unstable by design to increase combat performance and maneuverability. 

The General Dynamics F-16, developed in the early 1970s, was the first aircraft to employ this feature, known as Relaxed Static Stability, or RSS. Like other jet fighters designed since, the original variant of the F-16 employed a Digital Flight Control Computer, or FLCC, to take thousands of measurements a second from the flight control surfaces and apply corrections as needed in order to keep it from spiraling out of control. Current F-16 variants have had field upgrades to the MMC, produced by Raytheon.

As such, and by necessity of the design, the F-16 was the first “Fly By Wire” aircraft in the US arsenal with flight controls not directly connected to the control surfaces (which traditionally were mechanical/hydraulic in nature); they are purely electronic. One does not fly an F-16, it “flies you,” as many of its pilots have attested. 

Fly-by-Wire is now the standard way aircraft controls are now implemented in most modern commercial and military jet aircraft, and we are starting to see this in certain automotive designs as well, such as with my own Infiniti Q50 Red Sport that uses a Direct Adaptive Steering system. The Tesla vehicles employ some — but not all — of this technology, as the steering is electronically assisted, though still mechanically linked.

Ultimately, what this means is that the pilot does not have direct feedback from the aircraft’s control surfaces. They are only as good as what their instrumentation and what the flight control system allows him/her to “feel.” 

If you couple this with inherently unstable or relaxed stability, you then become extremely dependent on your flight control computer to keep the aircraft pointed where it needs to go. You become less of a pilot than the operator of a very sophisticated computer. 


These basic engineering changes spiraled into many other decisions that were made for the development of the 737 MAX, in the name of economics, expediency, and more efficient pilot training.

It would be easy to blame the programmers, developers and software processes of the 737 MAX’s MCAS for the two crashes, and that is what a lot of armchair aeronautics engineers are doing. We don’t really know what exactly is at fault here.

However, what this does reveal is that Boeing went to software as a patch for the modification to address performance flaws in a pre-existing systems architecture. It should have designed a completely new aircraft for this purpose. The A320 design was a good 20-year fresher, so it could accommodate the high-efficiency LEAP-1A and PW1000Gpowerplants much more naturally.

As Boeing learned with its previous exercises, the development of the 777 and the 787, it would have taken years longer to design a completely new plane. While the extra design time would have been a setback, in my personal opinion, it would have likely produced a superior, purpose-built aircraft. Now, because of these tragic losses, the entire future of the company is in question.


All this comes down to two basic things when developing any complex system: Problem identification and requirements gathering.

In my 25-plus years working in systems integration, I’ve seen the Boeing 737 MAX scenario appear way too many times. As a trusted adviser at companies like Unisys, IBM, Microsoft, and Dimension Data, I’ve cautioned my customers against using software as a patch for systems that for economic reasons or reasons of expediency, were not purpose-built. This applies not just to the most complex heterogeneous networks of systems but also small devices.

Yet regardless of my and my colleagues’ desires to have them correctly designed from scratch, I’ve seen these types of bespoke systems — that re-use legacy components — built often with unfortunate results when the systems are put in place and cannot reliably scale or perform.

In my field, we call this spaghetti architecture, or architecture by committee. It’s when you manage to put a lot of very smart people in the room, and they cannot agree precisely on the best solution.

How does this happen? It’s usually because they never truly defined the problem in the first place, or are never given the opportunity to gather the requirements to solve the actual problem. Or worse, their recommendations are ignored because of cost or time reasons — because the can was kicked down the road for too long and suddenly time becomes of the essence. 

To be fair, organizations such as Boeing often face difficult choices when managing legacy platforms. Close collaboration and consensus about a solution among engineers, management, customers, and other stakeholders is key when embarking on very large and complex systems integration efforts, such as retrofitting a legacy aircraft design with modernized propulsion systems.  

Frequently, customized off-the-shelf middleware or in-house code is created, such as the 737 MAX’s MCAS, to tie components together that were never intended to be tied together in the first place. Sometimes this works, and sometimes, despite the best efforts of even the most talented software development team, it fails to achieve optimal results. 


Boeing waited decades before realizing the 50-year-old 737 air frame was not suited to the new high-efficiency power plants. I have no doubt their engineers, under intense pressure from their management, did the very best they could with the parts they were given.

We can’t continually blame programmers and engineers who have to, under management pressure, create software bandages when it is determined that a complex system has flaws identified in their designs. This is especially important now with increasingly complex cloud and IoT systems attached to critical infrastructure, and with fly-by-wire aircraft, cars, and driverless systems, where human lives are at stake. 

The old stuff just doesn’t migrate well; it needs to be redesigned from scratch. We hope Boeing can now correct these issues without massive negative financial and reputational impact.

These systemic issues in the development of the aircraft may not be necessarily related to the crash. But did Boeing ignore best practices of problem definition and requirements gathering in the development of the 737 MAX? Talk Back and Let Me Know.