How to Crash an Airplane, by Nickolas Means
Abstract
On July 19, 1989, United Airlines Flight 232 was en route to Chicago when a mechanical failure caused the plane to become all but uncontrollable. In this unsurvivable situation, the flight crew saved more than half of those onboard. How did they do it?
Flight crews and software teams actually have a lot in common, and there's much we can learn from how the best crews do their jobs. What can we learn from the story of United 232? While this talk won't earn you your pilot's license, you'll definitely come away with some fresh ideas on how to make your team even more amazing.
Details
The talk will follow the narrative of United flight 232. The DC-10's tail-mounted engine fan blade exploded in flight, and the resulting shrapnel severed all three of the plane's redundant hydraulic systems, leaving the pilots almost no ability to control the plane. Yet, against almost-impossible odds, they managed a meandering approach to Sioux City, Iowa, and lined up for a relatively controlled crash.
The crash of UAL 232 is widely held as an example of the success of Crew Resource Management, a set of practices adopted in aviation in the early 1980's to encourage flight crews to make optimum use of all resources available to them (including each other) to increase safety. The concepts of CRM (situational awareness, communication, teamwork, flexibility and adaptability) are just as applicable to engineering teams as they are to flight crews.
During the 40 minutes between when the #2 fan blade initially explodes and the controlled crash at Sioux City, there are a significant number of key events and attitudes that lead to the eventual outcome. These points in the narrative give us several significant takeaways that can enhance how we work together as teams. Among them:
- Immediately after the #2 engine alarm, the captain asked the second officer to begin the engine failure checklist. Their immediate priority was to shut off the supply of fuel to the #2 engine to avoid a fire. When neither of the methods of fuel shutoff suggested by the engine failure checklist worked, the second officer suggested an alternate approach to the captain which he immediately endorsed. This worked, and fuel was shut off, averting a potential fire. This took 14 seconds. [Takeaway: Everyone on your team, no matter how new to software they are, has an opinion. Encourage them to speak their mind and have confidence making suggestions.]
- Shortly after that, the first officer pointed out to the captain that the plane was not responding to control inputs. Specifically, it was pitching down and to the right, despite his inputs up and to the left, and they were at risk of rolling completely inverted (which would be nearly unrecoverable even with full controls). The three quickly worked out a scheme to try and control the plane by varying the engine thrust and were able to get the plane to slowly level out. [Takeaway: Work together to find solutions to hard problems, and take credit together for solving them. Had the captain insisted on controlling the aircraft himself, the crew might not have come up with variable thrust control in time. None of the crew have ever taken individual credit for the suggestion either – it's the answer they came to as a group.]
- A DC-10 training pilot happened to be on board the aircraft, and when he realized that the crew were having trouble controlling the aircraft, he immediately offered his assistance to the flight attendant. The captain promptly invited him up to the cockpit, and he manned the throttles from that point until when the airplane crashed. [Takeaway: Take full advantage of the expertise around you. If someone knows more than you about a particular topic, learn everything you can from them instead of being envious or threatened.]
- As the plane was making its final approach (such as it was) into Sioux City, air traffic control notified the crew that they were "cleared to land on any runway". The captain can be heard on the radio recording chuckling as he acknowledged the clearance: "[laughter] Roger. [laughter] You want to be particular and make it a runway, huh?". [Takeaway: Our jobs don't typically involve life-or-death situations, but sometimes we struggle to maintain control of our emotions and our reactions. Captain Haynes, in the midst of the dire situation he found himself in, still managed to maintain the composure to crack a joke to air traffic control about his situation. This composure ultimately saved 185 lives. There are techniques that pilots use to build this kind of composure, and we can all learn from them.]
Pitch
Flight crews and software teams are both made up of individuals with widely varying levels of experience and expertise. This is especially true as Ruby is ever-more-widely adopted and the supply of available "5+ years of Ruby experience" engineers becomes spread further. It's essential that we continue to learn how to work together effectively in this mixed-experience environment.
Because of the lives at stake, the aviation field has put considerable research and effort into understanding how to make these mixed-experience teams as effective as possible, especially in stressful, fast-paced commercial airliner cockpits. We would be wise to consider this extensive research as we build our own teams, and that's the focus of this talk.
I'm a lifelong aviation geek, and particularly a student of aviation disasters. I've long been fascinated by the human dynamics in the cockpit that sometimes turn tiny equipment faults into horrific disasters and sometimes (as in the case of UAL 232) turn insurmountable problems into relative successes. This knowledge of how humans work together under extreme pressure has served me well as I've moved into an engineering leadership role, and I'd be thrilled to share it with others.
Submissions
The Lead Developer 2016 - Accepted [Edit]
RubyConf 2015 - Accepted [Edit]
Add submission