Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Mayday! Software Lessons from Aviation Disasters

Mayday! Software Lessons from Aviation Disasters

Adele Carpenter

June 16, 2021
Tweet

More Decks by Adele Carpenter

Other Decks in Programming

Transcript

  1. Photo by Chandler Cruttenden on Unsplash F-16 sonic boom? Lockerbie

    bombing Part II? Photo via wikimedia commons
  2. Finn gathers the team... • How can we prove ourselves

    wrong? • What details might we be ignoring? • What else could cause a mid-air break up? • What are the precise levels? Other sources of residue? • No terrorist groups have claimed credit • Countless possibilities, need to narrow the scope
  3. Photo by Chandler Cruttenden on Unsplash F-16 sonic boom? Lockerbie

    bombing Part II? Photo via wikimedia commons
  4. Question yourself • How can I prove myself wrong? •

    What details might I be ignoring because it doesn’t fit my theory or solution? • What else could cause this issue or situation?
  5. Improving software quality Finn’s top tips • Outcomes as a

    chain of events to learn from • Taking our time to investigate all options • Accepting responsibility our code - no “counterfeit code” • Following the evidence • Questioning ourselves rigorously
  6. Approximation of actual cockpit Photo by Keishi Nukina, KNaviation Captain

    McBroom First Officer Beebee Second Officer Frosty DC-8-61 Cockpit 28 December 1978 UA 173
  7. Approximation of actual cockpit Photo by Keishi Nukina, KNaviation Captain

    McBroom First Officer Beebee Second Officer Frosty DC-8-61 Cockpit 28 December 1978 UA 173
  8. The cause was the Captain’s failure to properly monitor the

    aircraft’s fuel state and to respond to both the low fuel state and the crew-member’s advisories regarding the fuel state. The factor contributing to the accident was the failure of Beebee and Frosty to either to fully comprehend the criticality of the fuel state or to successfully communicate their concern to the captain.
  9. Crew Resource Management Recommendations after UA 173 • Participative management

    for captains: in other words providing a non-threatening environment that actively encourages collaboration • Assertiveness training for other cockpit crew members: how to get your point across effectively in a non-threatening manner
  10. Situational Awareness Contributing Factors • Knowledge of the Automation and

    Abstractions present • Are you aware of the abstractions that you interact with, even if on a rudimentary level? Could you find the resources you need if the situation required it? Do you have a basic understanding of what happens when you run a Jenkins build? What’s it doing and what could go wrong? • Stress and Workload • How many tickets are assigned to you right now? How many meetings do you have planned? Which deadlines are real and which are arbitrary? Be honest with yourself and others on what you can accomplish
  11. Situational Awareness Contributing Factors • Physiological factors • Did you

    sleep enough? Are you hydrated? Did you eat? Did you poop? • Abilities, Experience, Training • What are your limitations or weak spots with respect to your role? How can you patch them? Who can help you? What knowledge could you share with others? • Preconceptions and bias • Is your gut instinct actually just bias? Why does a certain course of action appeal to you? What evidence do you have to support your position? Evidence against?
  12. Situational Awareness Is not a solo endeavour! • Contribute to

    a psychologically safe work environment • Share your knowledge, no matter your experience level • Speak up when things don’t add up