The 737 MAX and the question of who signs off on safety-critical code

Two crashes, one system

On 29 October 2018, Lion Air Flight 610 crashed into the Java Sea shortly after takeoff from Jakarta, killing all 189 people on board. On 10 March 2019, Ethiopian Airlines Flight 302 crashed shortly after departing Addis Ababa, killing all 157 on board. Both aircraft were Boeing 737 MAX 8s, and both crashes were linked to the Maneuvering Characteristics Augmentation System, or MCAS.

MCAS was software introduced to compensate for the aerodynamic effects of the 737 MAX's larger, repositioned engines. It could automatically push the aircraft's nose down based on a single angle-of-attack sensor reading, without cross-checking a second sensor, and without adequately informing pilots of its existence or behaviour.

Investigations by Indonesian and Ethiopian authorities, along with US agencies and later congressional inquiries, found that a faulty sensor reading triggered repeated, uncommanded nose-down inputs that crews were not trained to counteract quickly enough.

“A few hundred lines of flight-control logic, certified under commercial pressure, cost hundreds of lives.”

Certification under commercial pressure

Subsequent investigations, including a 2020 US House Transportation Committee report, found that Boeing had understated MCAS's authority to the Federal Aviation Administration during certification, and that FAA oversight relied heavily on Boeing employees to certify aspects of the aircraft's own safety under the Organization Designation Authorization programme.

The 737 MAX fleet was grounded worldwide from March 2019 until late 2020, one of the longest groundings in aviation history, while Boeing redesigned MCAS to rely on both angle-of-attack sensors and limited its authority to intervene.

The episode was not simply a hardware or aerodynamics failure; it was a failure of the software development and safety-assurance process, including inadequate hazard analysis of what would happen if the sensor feeding MCAS failed.

Lessons for software engineering practice

For the software engineering profession, the MCAS story is a case study in how commercial and schedule pressure can erode the rigour of safety analysis. Single points of sensor failure, inadequate failure-mode documentation and insufficient pilot disclosure all point to gaps in systems engineering discipline that any accredited engineer should recognise as unacceptable in a safety-critical context.

The Society's position

The Society holds that engineers working on safety-critical systems bear a professional and ethical duty that cannot be subordinated to commercial deadlines, regardless of where certification authority formally sits.

• Uphold codes of ethics that place public safety above employer or client instructions.
• Insist on independent verification of safety-critical software, separate from commercial certification pressure.
• Support licensure and registration frameworks that hold individual engineers accountable for safety sign-off.
• Promote rigorous failure-mode and redundancy analysis as a non-negotiable stage of systems design.