As an IT professional who is working DevSecOps and with strong interest in Aviation industry, I learnt some lessons from the grounding of 737-MAX series.

Automation is Essential but People Need to Know What Automation Does

The crash of ET302 and JT610 might be due to MCAS (Maneuvering Characteristics Augmentation System). The computer reads attitude of the plane and in certain situation it would intervene. It is meant to assist pilots and in ideal situation the pilots would not notice.

In DevSecOps, automation is essential; in fact without automation, it is not possible to achieve DevSecOps. Tools are used to achieve automation.

Use it right and in the hand of good engineers, the tools would do wonder. The DevSecOps would be able to deliver features, fixes, and updates frequently to deliver business values.

US Airway flight US1549 showed how a pilot, Capt. Sully, was able to utilise automation (in the form of auto pilot) to help him to steer the crippled plane before ditching on Hudson River.

In contrast, the computer on Air France flight AF447 provided warning to the pilots that the plane was stalling and approaching terra firma; however the pilots did not respond to the warning and only at last minute it figured out what happened, but it was too late.

In DevSecOps, it is common to mix different tools from different vendors. Each tool has its own strengths and the organisation may have its specific needs and constraints that dictate the tools used.

An engineer who is clue-less on the tools would make DevSecOps fail to deliver its value.

The engineer must be familiar with all of those tools. Using the tools everyday, however, does not make an engineer familiar with the tools; it was simply making the engineer as operator.

The engineer is expected to know how the tools work, how the tools interact to each others, how to exploit each individual tool, how to interpret the errors generated by the tools and how to fix the issues.

Not easy, but at least the engineer could quickly recover the tool-chain when there is/are error[s].

If an engineer is not familiar what each tool in tool-chain does, then he would not know what to do when something unexpected happened. In DevSecOps, it would simply created delays.

Unmanageable Technical Debt will Snowball to Bigger Problem in the Future

The Boeing 737-MAX is the latest variant of the venerable 737 series that started in the 60s. Throughout the years, Boeing kept improving the plane. It accommodate bigger engines, longer airframe (for bigger capacity), etc. It makes the plane still relevant, especially after Airbus rolled out A320s in the 80s.

However, what Boeing has been doing was simply continuously tweaking the plane. As the landing gears are not high, there is a limit on how big the engines 737 could use. Boeing has been tweaking the engine pylons so much that on 737-MAX the pilot needs to be assisted by the MCAS.

The Boeing 737 design has limited the changes that Boeing could do. It has become a technical debt but nothing was done.

Likewise in DevSecOps. While meeting the objective to deliver business values is very important, the technical debt also matters. Delaying addressing the technical debts would simply make the problem bigger and soon or later becomes unmanageable and affecting the business.

It is important for the organisation and DevSecOps team to allocate time and resources to address technical debt. It is either to be done in specific sprints/releases or inserted as part of releases.