# What Software Engineering can learn from Aviation Thursday, 15. April 2021 Is it not magical that an airplane crew that has possibly never worked together in this constellation can flawlessly execute a flight on an extremely complex airplane? A few key ingredients make that possible. Can Software Engineers learn from it? _Disclaimer: I am a licensed pilot, but I never worked with a Crew. I was lucky enough to have excellent instructors who work(ed) as Fighter Jet Pilot, KLM Boeing 747 Captain and Lufthansa Airbus A320 Captain. What I write about airplane crews comes from what I learned from them._ What unites the procedure to execute a flight is the so called _Crew Resource Management (CRM)_. NASA invented it after the number of fatalities came to a peak in the 1970s. Even though all pilots undergo long trainings to fly an airplane, most fatalities originate from human failure. With this observation, the idea was to change pilot’s trainings. Just being good at flying seems to miss a point. Comparing this observation to Software Engineering, just because a team comprises good coders does not mean the team is successful at building a great software product. CRM puts communication, leadership and decision making in the focus. I will describe how a crew works and how we could use these patterns in Software Engineering. ## The Mission Goal In aviation, the goal’s definition might be easier than in engineering. On a regular mission, the Crew wants to execute a _safe, orderly and expeditious_ flight, which is the “How”. _Flying an airplane from one point to another_ is the “What”. In Software Engineering, I have seen all kinds of goal definitions, from very heroic to measurable and time-bound. What these goals rarely contain is a prioritization of comprisable goals. Software Engineering does usually not have enough time or Engineers. Software Engineering is constrained. So is flying. You have what you have aboard, not more, not less. A Crew that needs to decide knows exactly what to put first: safety. Then comes orderly. Then expeditious. In a more tactical way this is _aviate, navigate, communicate_. Does a Software Engineer know what to put first when the goal is “By the end of this quarter, the time spent per task should reduce by 10%”? This is a “What” goal. We need the “How”. ### How to reach software engineering goals Let’s say we keep wording simple and give clear goals on how software should be like: 1. Readable 2. Correct 3. Reliable 4. Reusable 5. Extendable 6. Flexible 7. Efficient With an ordered list like this, there is a clear picture of _how_ to structure the development process. An Engineer trying to decrease time spent on a task will trade efficiency of the written software first, as it comes last in the priorities. This is an example. Order or content of this list should be adapted to the needs of the respective software project. ## Leadership Aviations “flat hierarchy” is widely known. The Captain has the last word but the Co-Pilot is an effective follower. ** Followership is a skill to learn**. I think Software Engineering gets this one quite right in most cases. Many teams have a dedicated lead developer. Hierarchies are usually flat in modern developer teams. I want to emphasise that Psychological Safety is the number one indicator for a well-performing team ([The five keys to a successful Google team](https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/)) . This is for both, leaders to foster respectful communication and followers to be assertive and respectful at the same time. ## Communication Communication skills are not given. The knowledge about communication is often told but not always incorporated. Most people have heard about how to make a proper appeal, how to do nonviolent communication, and most people have an intuition about the right tone. The biggest difference between aviation and software engineering is how often communication is addressed. **Airplane Crews speak about communication**. Usually in the briefing before the flight, the Captain mentions again that everyone is encouraged to communicate about issues they notice. Even though every single crew member learned about communication in their training, Crews address its importance frequently. In Engineering we sometimes assume communication. I think we can learn from aviation in a way to repeat how and why we want to communicate. Before I fly, I brief my passengers to tell me when they see something they find unusual. I tell them I take responsibility to notice unusual situations, but a second pair of eyes never hurts. I tell them even if they were my passengers before. ## Decision making One action I learned to take in aviation is to “sit on my hands” before falling for hasty measures. Usually no situation is so time critical that you can’t think about it for a few seconds. I remember when I was on approach for a small airport. The controller notified me there is an airplane stuck on the runway. She offered me to land on the grass strip next to it. On that day, a licensed pilot sat in the back of my airplane. He joined the flight as passenger. I informed him about the situation and that I would go for a landing on the grass strip. If anything feels unsafe, I would abort the landing. I asked for his opinion. He agreed. Instead of deviating or accepting the controller’s offer right away, I “sat on my hands” for a situation I never trained before, asked for more input, and took a decision after I could see the big picture again. It turns out that in critical and stressful situations, **humans fall back to behaviour they trained before** (This is also the reason you [should read the safety card](https://99percentinvisible.org/episode/in-the-unlikely-event/). In the “unlikely event”, you need to know how to get out). Usually as a Software Engineer, you have more time to think about decisions to make than when flying a plane. Still, production databases get accidentally deleted and other mistakes happen, especially in critical situations affecting production environments. If a Software Engineer would simulate stressful scenarios as part of their training, maybe failure rates would lower. If Software Engineers would repeat the process of decision making, risk calculations, asking for a second opinion, we could win uptime in production. ## Conclusion Finding analogies for software development was done in excess before. With this article, I don’t want to open another analogy by saying developing software is like flying an airplane. I want to explain how Software Engineering, and probably other disciplines too, can learn from Crew Resource Management. It is not the machinery or the craft skills; it is the incorporation of human factors that lead to the significant results modern aviation achieves and I would like to see more of the methodologies applied for Engineering. It requires discipline to work in the way outlined here, it is not “the sexy way” to work, but I am convinced it is worth the effort. By Raphael Sprenger