8 ms·

Trying to become a better developer by learning more about aviation

129 points by fcmam5 3y ago

rad_gruchalski 3y ago
This article isn't complete without mentioning DO-178C: Design guidance for aviation software development.
- karmelapple 3y ago
  And the different levels therein can help you think about your own systems, even if someone won’t crash a plane if your software fails. A large passenger aircraft does not solely consist of Level A software. There’s plenty of not-flight-safety-critical software on any airplane you ride as a civilian passenger, but there is some Level A software that could cause the worst consequences if it fails. Think about what pieces of your software are critical to your company/team’s mission, and which aren’t so bad if they fail. Not every line of code you write, or system you build, will wreak havoc on your company’s primary mission.
jacquesm 3y ago
Fantastich thread this, thank you fcmam5, I'm bookmarking this for future reference. My own contribution is to recommend reading risks digest: http://catless.ncl.ac.uk/Risks/ http://catless.ncl.ac.uk/Risks/
eschneider 3y ago
If you want to become a better developer through aviation, I can't recommend anything more highly than reading through NTSB accident reports. Learn from others the many, many ways small problems and misjudgements become accidents. It'll change the way you build things.
- jimkleiber 3y ago
  I'm really glad I stumbled on your comment. I train people in conflict resolution and emotional leadership and I've been looking for places to learn more about conflicts and causes and I think these NTSB reports could provide me a lot of examples from which to learn. They remind me of how at college I had a class on business communication and we discussed the communication issues that led to the Space Shuttle Challenger disaster. Thank you for recommending the NTSB reports :-)
  - eschneider 3y ago
    The cliff note version: More people die because they're in a hurry/feel pressured and push a marginal situation when they should have known better than you could possibly believe.
    - tialaramex 3y ago
      This is one of the sadder reasons why scheduled aviation is so safe. When flying planes is your job, why would you ever push your luck? I feel so tired, that storm looks pretty nasty, or the maintenance guy seemed like he had no idea why it's doing that - fuck it, we're not going, get the airline to put you on another plane if there is one, otherwise get them to pay for your hotel, I'm not flying anywhere today. One safeguard that is needed, and I believe is provided even in the US - is a strong union to ensure that "Because I'll get fired unless we go" isn't the answer. People in safety critical roles must be protected so that "No" is always an option for them. For private pilots, reasons to push your luck sneak over from real life. To get home before the twins are asleep. To be back in time for work tomorrow. So that I don't miss Trisha's wedding. Because the replacement was very expensive and I can't afford it right now. The fuel prices are lower back home, we'll fill up there.
      - bombcar 3y ago
        My CFI said "graveyards are full of people the world couldn't do without, it can wait a day" - important to remember for many things, if you start pushing your luck it'll eventually push back.
        sokoloff 3y ago
        “NTSB investigators usually wear sunglasses.” Meaning that will likely be investigating your weather accident in the sunshine, so you could just wait a short while and fly in that good weather rather than crashing right now.
        bombcar 3y ago
- _dain_ 3y ago
  A lot of this wisdom is summarized in the book The Field Guide to Understanding "Human Error" by Sidney Dekker. I learned of it from this talk about Three Mile Island: https://www.youtube.com/watch?v=hMk6rF4Tzsg https://www.youtube.com/watch?v=hMk6rF4Tzsg
- civilitty 3y ago
  There's also a lot to learn about the differences in solo work vs teamwork. The swiss cheese model plays out differently when it's GA vs airliners. NTSB reports for general aviation tend to focus on individual mistakes since that's most often solo pilots with no ground crew, but for commercial flights it's generally a more complex series of mistakes made in a team.
- jasonpeacock 3y ago
  Similarly, Accidents in North American Mountaineering[1] covers failures and their factors and is good reading. [1] https://publications.americanalpineclub.org/about_the_accidents https://publications.americanalpineclub.org/about_the_accide...
  - thenobsta 3y ago
    I took a self-rescue course and a list at the end of their handout had such good engineering tips that I shared it with my eng team. Lots to be learned about engineering from climbing/mountaineering. The list was something like the following: A few pro-tips: - Slow is smooth. Smooth is fast. - Simplicity/speed/efficiency is good. - Strong is good. Redundancy is good/better. - Equalization and Extension are a trade off. - Not everything is a nail so NOT every tool is a hammer. - Tools that have multiple uses are good.
- Animats 3y ago
  It takes two major failures or errors today to cause the crash of a commercial transport aircraft. All the single points of failure have been fixed. You'll see this repeatedly in NTSB reports. Failure or event A happened, and then failure or event B happened. Single-event crashes of airliners are very, very rare.
  - JohnFen 3y ago
    > All the single points of failure have been fixed. Now you've jinxed it!
- evil-olive 3y ago
  for approachable summaries of those accident reports, I'd recommend Admiral Cloudberg's "Plane Crash Series" on Medium [0] and Reddit [1], as well as YouTube videos from Mentour Pilot [2]. the latter's videos tend to have clickbait-y titles to make the YouTube algorithm happy, but the content is excellent. 0: https://admiralcloudberg.medium.com/ https://admiralcloudberg.medium.com/ 1: https://www.reddit.com/r/AdmiralCloudberg/comments/e6n80m/plane_crash_series_archive_patreon_contact_info/ https://www.reddit.com/r/AdmiralCloudberg/comments/e6n80m/pl... 2: https://www.youtube.com/@MentourPilot https://www.youtube.com/@MentourPilot
  - ohdannyboy 3y ago
    +1 for Mentour, being a commercial pilot himself his insights are fantastic.
- jacquesm 3y ago
  And risks digest.
- sklargh 3y ago
  Agree with the above, fabulous learning tool. A theme that often dominates is small mistakes deep paid for with blood and treasure at usurious interest rates. I also recommend Admiral Cloudberg. https://admiralcloudberg.medium.com/drama-in-the-snow-the-crash-of-scandinavian-airlines-flight-751-41b05fb442fd https://admiralcloudberg.medium.com/drama-in-the-snow-the-cr...
LorenPechtel 3y ago
I very much believe in swiss cheese safety systems. There *will* be errors, you try to avoid them becoming catastrophes. And I hate systems that don't let you say "ignore *this* warning" without turning off all warnings. I have some Tile trackers with dead batteries--but there's no way I can tell the app to ignore *that* dead battery yet tell me about any new ones that are growing weak. (We haven't been using our luggage, why should I replace the batteries until such day as the bags are going to leave the house again?)
KolmogorovComp 3y ago
> NATO Phonetic alphabet (Alpha, Bravo, Charlie…). NIT, A is written as Alfa in the NATO alphabet [0] as it is easier to understand its pronunciation. For the same reason J is written as Juliett (two t), because in some languages t can be silent. [0] https://en.wikipedia.org/wiki/NATO_phonetic_alphabet https://en.wikipedia.org/wiki/NATO_phonetic_alphabet
- gbacon 3y ago
  Don't forget their cousins "tree" and "fife" — or the overpronunciation of Papa as /papà/.
  - KolmogorovComp 3y ago
    As well as "niner", but I didn't want to delve into all the subtleties.
  - josefrichter 3y ago
    I once heard a recording of a conversation between ATC and an aircraft with a registration OK-PPP. Every communication from either side starts with Oskar Kilo Papapapapapa :-)
  - psunavy03 3y ago
    No one actually uses "tree" and "fife."
gbacon 3y ago
Fun to consider as both a computer scientist and a CFI. Instrument training in FAA-land requires learners to understand the five hazardous attitudes: anti-authority ("the rules don't apply to me"), impulsivity ("gotta do something now!), invulnerability ("I can get away with it"), macho ("watch this!"), and resignation ("I can't do anything to stop the inevitable"). Although the stakes are different, they have applicability to software development. Before a situation gets out of hand, the pilot has to recognize and label a particular thought and then think of the antidote, e.g., "the rules are there to keep me safe" for anti-authority. Part 121 or scheduled airline travel owes its safety record to many layers of redundancy. Two highly trained and experienced pilots are in the cockpit talking to a dispatcher on the ground, for example. They're looking outside and also have Air Traffic Control watching out for them. The author mentioned automation. This is an area where DevSecOps pipelines can add lots of redundancy in a way that leaves machines doing tedious tasks that machines are good at. As in the cockpit, it's important to understand and manage the automation rather than following the magenta line right into cumulogranite.
- m463 3y ago
  The attitudes are interesting. WRT development, I wonder if there are attitudes that can be applied to software and hardware design that combat bad systems. For example, cars with touchscreens instead of individual controls.
- bulte-rs 3y ago
  Former airline pilot checking in! Remember the importance of checklists in the "grand scheme of things". It helps maintain proper "authority" during operation and makes sure you don't forget things. If you don't write it down and check it, someone, at a certain moment will forget something. Also, the "Aviate, navigate, communicate" axiom (as mentioned by author) is really helpful if you're trying to setup incident/crisis response structures. You basically get your guiding principles for free from an industry that has 100+ years of experience in dealing with crisises. It's something I teach during every incident/crisis response workshop. edit: Although it's not aviation specific, and a little light on the science, "The Checklist Manifesto" by A. Gawande is a nice introduction into using (and making) checklists.
Animats 3y ago
Minor lessons from time at an aerospace company: - When your device is in use in the field, the user will be too hot, too cold, too windy, too dark, too tired, too wet, too rushed, or under fire. Mistakes will be made. Design for that environment. Simplify controls. Make layouts very clear. Military equipment uses connectors which cannot be plugged in wrong, even if you try to force them. That's why. (Former USMC officer.) - Make it easy to determine what's broken. Self-test features are essential. (USAF officer.) - If A and B won't interoperate, check the interface specification. Whoever isn't compliant with the spec is wrong. They have to fix their side. If you can't decide who's wrong, the spec is wrong. This reduces interoperability from an O(N^2) problem to an O(N) problem. (DARPA program manager.) - If the thing doesn't meet spec, have Q/A put a red REJECTED tag on it. The thing goes back, it doesn't get paid for, the supplier gets pounded on by Purchasing and Quality Control, and they get less future business. It's not your job to fix their problem. (This was from an era when DoD customers had more clout with suppliers.) - There are not "bugs". There are "defects". (HP exec.) - Let the fighter pilot drive. Just sit back and enjoy the world zooming by. (Navy aviator.) Aerospace is a world with many hard-ass types, many of whom have been shot at and shot back, have landed a plane in bad weather, or both.
- SoftTalker 3y ago
  I like the term "defect" it's more accurate than "bug."
  - treve 3y ago
    Is it? I think the definition of Bug is literally defect. Maybe it carries a different 'weight' for some people?
    - tdubhro1 3y ago
      I think for many people “Bug” can imply something that crawled in from outside and messed up the system, “defect” implies that there was an avoidable deficiency in the specification or the implementation. The engineering mindset might prefer “defect” since it implies that we can fix the process and improve the quality of future products, whereas “bug” implies these things are just a fact of life and you can’t expect to eliminate them
warner25 3y ago
It seems like there are almost daily HN front page items about aviation, and a lot of pilots in the comments. I've wondered about the reasons for such an overlap in interests among people here. I fit this myself: I grew up playing flight simulators, studied computer science as an undergrad, was a military helicopter pilot for a while, and then went to grad school for computer science. Along the way, I've personally met at least half a dozen other academic computer scientists with a pilot's license or military aviation background. Is it just selective attention / frequency illusion for me, or is there more to this?
- JohnFen 3y ago
  > I've wondered about the reasons for such an overlap in interests among people here. I bet that a large part of why is that people here tend to have reasonably high incomes, and flying is an expensive hobby. I'm sure that flying would be an incredibly popular hobby across all demographics if it were affordable.
  - samtho 3y ago
    Flying was not as expensive as I thought especially since I found a school that lets you pay by the lesson. Once you got your 40 hours, you can, without much restriction, fly general aviation aircraft (that you are type-rated on) wherever you want in the US at least. A non club price puts a Cessna at about $110-$160/hr wet (time engine is on, 100LL Avgas included). Expensive, but not so out of reach. The thing you need to be rich in is free time. You can have all the money in the world but if you don’t have the time to put in, you’re not getting into this hobby.
- josefrichter 3y ago
  I studied Air Traffic Management = basically managing and evolving ATC systems. I work now as a product designer, which for the most part involves conceptual design, dealing with complex flows and optimising them, dealing with imperfect humans using those systems, "solving problems" that go far beyond design. I often say it's the exact same job, just in slightly different domain.
- 3y ago
SoftTalker 3y ago
Makes sense if your software is responsible for keeping people alive. Most of us don't need to work to such a standard (thankfully).
- syndicatedjelly 3y ago
  There’s a certain level of arrogance that comes from the people who don’t work on safety critical stuff, that we could all do without
  - ryandrake 3y ago
    I always thought “well, nobody’s gonna die” is a crappy attitude for any professional developer. We should care about quality and getting it right, regardless of the stakes. QA: ”Look, if that integer overflows here, your software is going to fail.” Dev: “Well, it’s a cooking recipe app. Nobody’s gonna die!” How low of an opinion you must have of your own profession if you’re going to excuse yourself this way!
    - SoftTalker 3y ago
      Have you ever written avionics-grade software? If all software had to be written to that standard, we'd have a lot less of it. That might be a good thing I guess, but recipe apps probably wouldn't make the cut.
      - tonyarkles 3y ago
        Yeah, there’s a middle ground there. I work on non-flight-critical software that goes on large drones. We don’t do DO-178C for cost and schedule purposes, but because the system and crew is expensive and flies on tight timelines (covering as many acres as possible during daylight hours), we take system reliability very seriously. It definitely takes more time, but we’ve had the system limp through some pretty wild hardware failures just fine (while immediately notifying the ground crew that the system is degraded). Having an aviation mindset has absolutely helped us make really robust software.
maxbond 3y ago
I had a similar experience, and found "aviate, navigate, communicate" to be an excellent model for responding to production incidents.
hcarvalhoalves 3y ago
> Build for resiliency and designed to fail safely This is important, but I'm not sure everybody necessarily agrees on what "fail safely" means. Fail safely can mean one of: - It doesn't fail silently - It doesn't cause cascading failures - It doesn't cause infinite failure loops - It doesn't fail in ways that corrupt data - It doesn't fail in ways you lose money - You can safely retry - You can safely retry anytime (not just today, or just this month)
akhayam 3y ago
I have taken so much inspiration aviation industry when designing and operating software system. In addition to the inspirations mentioned in this blog, I find the idea of "antifragility" in aviation quite fascinating, where every near miss is studied, documented and checklisted across the entire aviation industry. This means that every near miss improves the resilience of the entire industry. We need to build similar means of learning from others' mistakes in complex software systems as well.
WalterBright 3y ago
Control reversal, when the surfaces move opposite from the command, have happened. They nearly always result in a crash. How does Boeing prevent controls from being hooked up backwards? The hydraulic actuators (rams) have an input and an output port. Connecting the hydraulic lines to the wrong port results in control reversal. To defend against that: 1. One port has left handed threads, the other right handed threads 2. The ports are different sizes 3. The ports are color coded 4. The lines cannot be bent to reach the wrong port 5. Any work on it has to be checked, tested, and signed off by another mechanic And finally: 5. Part of the preflight checklist is to verify that the control surfaces move the right way I haven't heard of a control reversal on airliners built this way, but I have heard of it happening in older aircraft after an overhaul.
WalterBright 3y ago
As a former Boeing flight controls engineer, I wrote a couple articles about lessons that transfer to software: Safe Systems from Unreliable Parts https://www.digitalmars.com/articles/b39.html https://www.digitalmars.com/articles/b39.html Designing Safe Software Systems Part 2 https://www.digitalmars.com/articles/b40.html https://www.digitalmars.com/articles/b40.html
- mips_r4300i 3y ago
  Good points. Embedded systems deal with many of those. It made me think of a funny story that causes me to pay closer attention to things like this: Some time ago I shipped a product running an RTOS which unfortunately had a subtle scheduler bug where it would randomly crash periodically. The bug was pretty rare (I thought), only affecting part of the system, and reproducing the bug took several days each time. In my infinite genius, rather than waste weeks of valuable time up to release, I set up the watchdog timer on the processor to write a crash dump and silently reboot. A user would maybe see a few seconds of delayed input and everything would come back up shortly. Unfortunately, I had accidentally set the watchdog clock divider the wrong way, resulting in the watchdog not activating for over 17 hours after a hang! The bug became much more widely noticeable after the product was released, and only by sheer luck, many people never noticed it. I eventually fixed the scheduler bug in an update, but the useless watchdog configuration was set in stone and not fixable. Taught me to never assume a rare bug would stay rare when many tens of thousands of people use something in the field.
vunderba 3y ago
When I started working for more consumer facing application developing companies, I tried to adopt the software developers equivalent of "if you're the developer of a new experimental plane, you're the first to go up in the said plane."
deathanatos 3y ago
It's a lot of good advice, but IME the next step is "but how do I actually do this?" A lot of the difficultly boils down to an inverse NIH syndrome: we outsource monitoring and alerting … and the systems out there are quite frankly pretty terrible. We struggle with alert routing, because alert routing should really take a function that takes alert data in and figures out what to do with it … but Pagerduty doesn't support that. Datadog (monitoring) struggles (struggles) with sane units, and IME with aliasing. DD will also alert on things that … don't match the alert criteria? (We've still not figured that one out.) “Aviate, Navigate, Communicate” definitely is a good idea, but let me know if you figure out how to teach people to communicate. Many of my coworkers lack basic Internet etiquette. (And I'm pretty sure "netiquette" died a long time ago.) The Swiss Cheese model isn't just about having layers to prevent failures. The inverse axiom is where the fun starts: the only failures you see, by definition, are the ones that go through all the holes in the cheese simultaneously. If they didn't, then by definition, a layer of swiss has stopped the outage. That means "how can this be? like n different things would have to be going wrong, all at the same time" isn't really an out in an outage: yes, by definition! This is too, of course, assuming you know what holes are in your cheese, and often, the cheese is much holier than people seem to think it is. I'm always going to hard disagree with runbooks, though. Most failures are of the "it's a bug" variety: there is no possible way to write the runbook for them. If you can write a runbook, that means you're aware of the bug: fix the bug, instead. The rest is bugs you're unaware of, and to write a runbook would thus require clairvoyance. (There are limited exceptions to this: sometimes you cannot fix the bug: e.g., if the bug lies in a vendor's software and the vendor refuses to do anything about it¹, then you're just screwed, and have to write down the next best work around, particularly if any workaround is hard to automate. There are other pressures, like PMs who don't give devs the time to fix bugs, but in general runbooks are a drag on productivity, as they're manual processes you're following in lieu of a working system. Be pragmatic about when you take them on (if you can). > Have a “Ubiquitous language” This one, this one is the real gem. I beg of you, please, do this. A solid ontology prevents bugs. This gets back to the "teach communication" problem, though. I work with devs who seem to derive pleasure from inventing new terms to describe things that already have terms. Communicating with them is a never ending game of grabbing my crystal ball and decoding WTF it is they're talking about. Also, I know the NATO alphabet (I'm not military/aviation). It is incredibly useful, and takes like 20-40 minutes of attempting to memorize it to get it. It is mind boggling that customer support reps do not learn this, given how shallow the barrier to entry is. (They could probably get away with like, 20 minutes of memorization & then learn the rest just via sink-or-swim.) (I also have what I call malicious-NATO: "C, as in sea", "Q, as in cue", "I, as in eye", "R, as in are", U, as in "you", "Y, as in why") > Don’t write code when you are tired. Yeah, don't: https://www.cdc.gov/niosh/emres/longhourstraining/impaired.html https://www.cdc.gov/niosh/emres/longhourstraining/impaired.h... And yet I regularly encounter orgs or people suggesting that deployments should occur well past the 0.05% BAC equivalent mark. "Unlimited PTO" … until everyone inevitably desires Christmas off and then push comes to shove. Some of this intertwines with common PM failure modes, too: I have, any number of times, been pressed for time estimates on projects where we don't have a good time estimate because there are two many unknowns in the project. (Typically because whomever is PM … really hasn't done their job in the first place of having even the foggiest understanding of what's actually involved, inevitably because the PM is non-technical. Having seen a computer is not technical.) When the work is then broken out and estimates assigned to the broken out form, the total estimate is rejected, because PMs/management don't like the number. Then inevitably a date is chosen at random by management. (And the number of times I've had a Saturday chosen is absurd, too.) And then the deadline is missed. Sometimes, projects skip right to the arbitrary deadline step, which at least cuts out some pointless debate about, yes, what you're proposing really is that complicated. That's stressful, PMs. ¹ cough Azure cough excuse me.
r2on3nge 3y ago
This is so fascinating! Continuing becoming better and better everyday.

129 points by fcmam5 3y ago

rad_gruchalski 3y ago

This article isn't complete without mentioning DO-178C: Design guidance for aviation software development.

karmelapple 3y ago
And the different levels therein can help you think about your own systems, even if someone won’t crash a plane if your software fails. A large passenger aircraft does not solely consist of Level A software. There’s plenty of not-flight-safety-critical software on any airplane you ride as a civilian passenger, but there is some Level A software that could cause the worst consequences if it fails. Think about what pieces of your software are critical to your company/team’s mission, and which aren’t so bad if they fail. Not every line of code you write, or system you build, will wreak havoc on your company’s primary mission.

jacquesm 3y ago

Fantastich thread this, thank you fcmam5, I'm bookmarking this for future reference. My own contribution is to recommend reading risks digest: http://catless.ncl.ac.uk/Risks/ http://catless.ncl.ac.uk/Risks/

eschneider 3y ago

If you want to become a better developer through aviation, I can't recommend anything more highly than reading through NTSB accident reports. Learn from others the many, many ways small problems and misjudgements become accidents. It'll change the way you build things.

jimkleiber 3y ago
I'm really glad I stumbled on your comment. I train people in conflict resolution and emotional leadership and I've been looking for places to learn more about conflicts and causes and I think these NTSB reports could provide me a lot of examples from which to learn. They remind me of how at college I had a class on business communication and we discussed the communication issues that led to the Space Shuttle Challenger disaster. Thank you for recommending the NTSB reports :-)
- eschneider 3y ago
  The cliff note version: More people die because they're in a hurry/feel pressured and push a marginal situation when they should have known better than you could possibly believe.
  - tialaramex 3y ago
    This is one of the sadder reasons why scheduled aviation is so safe. When flying planes is your job, why would you ever push your luck? I feel so tired, that storm looks pretty nasty, or the maintenance guy seemed like he had no idea why it's doing that - fuck it, we're not going, get the airline to put you on another plane if there is one, otherwise get them to pay for your hotel, I'm not flying anywhere today. One safeguard that is needed, and I believe is provided even in the US - is a strong union to ensure that "Because I'll get fired unless we go" isn't the answer. People in safety critical roles must be protected so that "No" is always an option for them. For private pilots, reasons to push your luck sneak over from real life. To get home before the twins are asleep. To be back in time for work tomorrow. So that I don't miss Trisha's wedding. Because the replacement was very expensive and I can't afford it right now. The fuel prices are lower back home, we'll fill up there.
    - bombcar 3y ago
      My CFI said "graveyards are full of people the world couldn't do without, it can wait a day" - important to remember for many things, if you start pushing your luck it'll eventually push back.
      - sokoloff 3y ago
        “NTSB investigators usually wear sunglasses.” Meaning that will likely be investigating your weather accident in the sunshine, so you could just wait a short while and fly in that good weather rather than crashing right now.
        bombcar 3y ago
_dain_ 3y ago
A lot of this wisdom is summarized in the book The Field Guide to Understanding "Human Error" by Sidney Dekker. I learned of it from this talk about Three Mile Island: https://www.youtube.com/watch?v=hMk6rF4Tzsg https://www.youtube.com/watch?v=hMk6rF4Tzsg
civilitty 3y ago
There's also a lot to learn about the differences in solo work vs teamwork. The swiss cheese model plays out differently when it's GA vs airliners. NTSB reports for general aviation tend to focus on individual mistakes since that's most often solo pilots with no ground crew, but for commercial flights it's generally a more complex series of mistakes made in a team.
jasonpeacock 3y ago
Similarly, Accidents in North American Mountaineering[1] covers failures and their factors and is good reading. [1] https://publications.americanalpineclub.org/about_the_accidents https://publications.americanalpineclub.org/about_the_accide...
- thenobsta 3y ago
  I took a self-rescue course and a list at the end of their handout had such good engineering tips that I shared it with my eng team. Lots to be learned about engineering from climbing/mountaineering. The list was something like the following: A few pro-tips: - Slow is smooth. Smooth is fast. - Simplicity/speed/efficiency is good. - Strong is good. Redundancy is good/better. - Equalization and Extension are a trade off. - Not everything is a nail so NOT every tool is a hammer. - Tools that have multiple uses are good.
Animats 3y ago
It takes two major failures or errors today to cause the crash of a commercial transport aircraft. All the single points of failure have been fixed. You'll see this repeatedly in NTSB reports. Failure or event A happened, and then failure or event B happened. Single-event crashes of airliners are very, very rare.
- JohnFen 3y ago
  > All the single points of failure have been fixed. Now you've jinxed it!
evil-olive 3y ago
for approachable summaries of those accident reports, I'd recommend Admiral Cloudberg's "Plane Crash Series" on Medium [0] and Reddit [1], as well as YouTube videos from Mentour Pilot [2]. the latter's videos tend to have clickbait-y titles to make the YouTube algorithm happy, but the content is excellent. 0: https://admiralcloudberg.medium.com/ https://admiralcloudberg.medium.com/ 1: https://www.reddit.com/r/AdmiralCloudberg/comments/e6n80m/plane_crash_series_archive_patreon_contact_info/ https://www.reddit.com/r/AdmiralCloudberg/comments/e6n80m/pl... 2: https://www.youtube.com/@MentourPilot https://www.youtube.com/@MentourPilot
- ohdannyboy 3y ago
  +1 for Mentour, being a commercial pilot himself his insights are fantastic.
jacquesm 3y ago
And risks digest.
sklargh 3y ago
Agree with the above, fabulous learning tool. A theme that often dominates is small mistakes deep paid for with blood and treasure at usurious interest rates. I also recommend Admiral Cloudberg. https://admiralcloudberg.medium.com/drama-in-the-snow-the-crash-of-scandinavian-airlines-flight-751-41b05fb442fd https://admiralcloudberg.medium.com/drama-in-the-snow-the-cr...

LorenPechtel 3y ago

I very much believe in swiss cheese safety systems. There *will* be errors, you try to avoid them becoming catastrophes. And I hate systems that don't let you say "ignore *this* warning" without turning off all warnings. I have some Tile trackers with dead batteries--but there's no way I can tell the app to ignore *that* dead battery yet tell me about any new ones that are growing weak. (We haven't been using our luggage, why should I replace the batteries until such day as the bags are going to leave the house again?)

KolmogorovComp 3y ago

> NATO Phonetic alphabet (Alpha, Bravo, Charlie…). NIT, A is written as Alfa in the NATO alphabet [0] as it is easier to understand its pronunciation. For the same reason J is written as Juliett (two t), because in some languages t can be silent. [0] https://en.wikipedia.org/wiki/NATO_phonetic_alphabet https://en.wikipedia.org/wiki/NATO_phonetic_alphabet

gbacon 3y ago
Don't forget their cousins "tree" and "fife" — or the overpronunciation of Papa as /papà/.
- KolmogorovComp 3y ago
  As well as "niner", but I didn't want to delve into all the subtleties.
- josefrichter 3y ago
  I once heard a recording of a conversation between ATC and an aircraft with a registration OK-PPP. Every communication from either side starts with Oskar Kilo Papapapapapa :-)
- psunavy03 3y ago
  No one actually uses "tree" and "fife."

gbacon 3y ago

Fun to consider as both a computer scientist and a CFI. Instrument training in FAA-land requires learners to understand the five hazardous attitudes: anti-authority ("the rules don't apply to me"), impulsivity ("gotta do something now!), invulnerability ("I can get away with it"), macho ("watch this!"), and resignation ("I can't do anything to stop the inevitable"). Although the stakes are different, they have applicability to software development. Before a situation gets out of hand, the pilot has to recognize and label a particular thought and then think of the antidote, e.g., "the rules are there to keep me safe" for anti-authority. Part 121 or scheduled airline travel owes its safety record to many layers of redundancy. Two highly trained and experienced pilots are in the cockpit talking to a dispatcher on the ground, for example. They're looking outside and also have Air Traffic Control watching out for them. The author mentioned automation. This is an area where DevSecOps pipelines can add lots of redundancy in a way that leaves machines doing tedious tasks that machines are good at. As in the cockpit, it's important to understand and manage the automation rather than following the magenta line right into cumulogranite.

m463 3y ago
The attitudes are interesting. WRT development, I wonder if there are attitudes that can be applied to software and hardware design that combat bad systems. For example, cars with touchscreens instead of individual controls.
bulte-rs 3y ago
Former airline pilot checking in! Remember the importance of checklists in the "grand scheme of things". It helps maintain proper "authority" during operation and makes sure you don't forget things. If you don't write it down and check it, someone, at a certain moment will forget something. Also, the "Aviate, navigate, communicate" axiom (as mentioned by author) is really helpful if you're trying to setup incident/crisis response structures. You basically get your guiding principles for free from an industry that has 100+ years of experience in dealing with crisises. It's something I teach during every incident/crisis response workshop. edit: Although it's not aviation specific, and a little light on the science, "The Checklist Manifesto" by A. Gawande is a nice introduction into using (and making) checklists.

Animats 3y ago

Minor lessons from time at an aerospace company: - When your device is in use in the field, the user will be too hot, too cold, too windy, too dark, too tired, too wet, too rushed, or under fire. Mistakes will be made. Design for that environment. Simplify controls. Make layouts very clear. Military equipment uses connectors which cannot be plugged in wrong, even if you try to force them. That's why. (Former USMC officer.) - Make it easy to determine what's broken. Self-test features are essential. (USAF officer.) - If A and B won't interoperate, check the interface specification. Whoever isn't compliant with the spec is wrong. They have to fix their side. If you can't decide who's wrong, the spec is wrong. This reduces interoperability from an O(N^2) problem to an O(N) problem. (DARPA program manager.) - If the thing doesn't meet spec, have Q/A put a red REJECTED tag on it. The thing goes back, it doesn't get paid for, the supplier gets pounded on by Purchasing and Quality Control, and they get less future business. It's not your job to fix their problem. (This was from an era when DoD customers had more clout with suppliers.) - There are not "bugs". There are "defects". (HP exec.) - Let the fighter pilot drive. Just sit back and enjoy the world zooming by. (Navy aviator.) Aerospace is a world with many hard-ass types, many of whom have been shot at and shot back, have landed a plane in bad weather, or both.

SoftTalker 3y ago
I like the term "defect" it's more accurate than "bug."
- treve 3y ago
  Is it? I think the definition of Bug is literally defect. Maybe it carries a different 'weight' for some people?
  - tdubhro1 3y ago
    I think for many people “Bug” can imply something that crawled in from outside and messed up the system, “defect” implies that there was an avoidable deficiency in the specification or the implementation. The engineering mindset might prefer “defect” since it implies that we can fix the process and improve the quality of future products, whereas “bug” implies these things are just a fact of life and you can’t expect to eliminate them

warner25 3y ago

It seems like there are almost daily HN front page items about aviation, and a lot of pilots in the comments. I've wondered about the reasons for such an overlap in interests among people here. I fit this myself: I grew up playing flight simulators, studied computer science as an undergrad, was a military helicopter pilot for a while, and then went to grad school for computer science. Along the way, I've personally met at least half a dozen other academic computer scientists with a pilot's license or military aviation background. Is it just selective attention / frequency illusion for me, or is there more to this?

JohnFen 3y ago
> I've wondered about the reasons for such an overlap in interests among people here. I bet that a large part of why is that people here tend to have reasonably high incomes, and flying is an expensive hobby. I'm sure that flying would be an incredibly popular hobby across all demographics if it were affordable.
- samtho 3y ago
  Flying was not as expensive as I thought especially since I found a school that lets you pay by the lesson. Once you got your 40 hours, you can, without much restriction, fly general aviation aircraft (that you are type-rated on) wherever you want in the US at least. A non club price puts a Cessna at about $110-$160/hr wet (time engine is on, 100LL Avgas included). Expensive, but not so out of reach. The thing you need to be rich in is free time. You can have all the money in the world but if you don’t have the time to put in, you’re not getting into this hobby.
josefrichter 3y ago
I studied Air Traffic Management = basically managing and evolving ATC systems. I work now as a product designer, which for the most part involves conceptual design, dealing with complex flows and optimising them, dealing with imperfect humans using those systems, "solving problems" that go far beyond design. I often say it's the exact same job, just in slightly different domain.
3y ago

SoftTalker 3y ago

Makes sense if your software is responsible for keeping people alive. Most of us don't need to work to such a standard (thankfully).

syndicatedjelly 3y ago
There’s a certain level of arrogance that comes from the people who don’t work on safety critical stuff, that we could all do without
- ryandrake 3y ago
  I always thought “well, nobody’s gonna die” is a crappy attitude for any professional developer. We should care about quality and getting it right, regardless of the stakes. QA: ”Look, if that integer overflows here, your software is going to fail.” Dev: “Well, it’s a cooking recipe app. Nobody’s gonna die!” How low of an opinion you must have of your own profession if you’re going to excuse yourself this way!
  - SoftTalker 3y ago
    Have you ever written avionics-grade software? If all software had to be written to that standard, we'd have a lot less of it. That might be a good thing I guess, but recipe apps probably wouldn't make the cut.
    - tonyarkles 3y ago
      Yeah, there’s a middle ground there. I work on non-flight-critical software that goes on large drones. We don’t do DO-178C for cost and schedule purposes, but because the system and crew is expensive and flies on tight timelines (covering as many acres as possible during daylight hours), we take system reliability very seriously. It definitely takes more time, but we’ve had the system limp through some pretty wild hardware failures just fine (while immediately notifying the ground crew that the system is degraded). Having an aviation mindset has absolutely helped us make really robust software.

maxbond 3y ago

I had a similar experience, and found "aviate, navigate, communicate" to be an excellent model for responding to production incidents.

hcarvalhoalves 3y ago

> Build for resiliency and designed to fail safely This is important, but I'm not sure everybody necessarily agrees on what "fail safely" means. Fail safely can mean one of: - It doesn't fail silently - It doesn't cause cascading failures - It doesn't cause infinite failure loops - It doesn't fail in ways that corrupt data - It doesn't fail in ways you lose money - You can safely retry - You can safely retry anytime (not just today, or just this month)

akhayam 3y ago

I have taken so much inspiration aviation industry when designing and operating software system. In addition to the inspirations mentioned in this blog, I find the idea of "antifragility" in aviation quite fascinating, where every near miss is studied, documented and checklisted across the entire aviation industry. This means that every near miss improves the resilience of the entire industry. We need to build similar means of learning from others' mistakes in complex software systems as well.

WalterBright 3y ago

Control reversal, when the surfaces move opposite from the command, have happened. They nearly always result in a crash. How does Boeing prevent controls from being hooked up backwards? The hydraulic actuators (rams) have an input and an output port. Connecting the hydraulic lines to the wrong port results in control reversal. To defend against that: 1. One port has left handed threads, the other right handed threads 2. The ports are different sizes 3. The ports are color coded 4. The lines cannot be bent to reach the wrong port 5. Any work on it has to be checked, tested, and signed off by another mechanic And finally: 5. Part of the preflight checklist is to verify that the control surfaces move the right way I haven't heard of a control reversal on airliners built this way, but I have heard of it happening in older aircraft after an overhaul.

WalterBright 3y ago

As a former Boeing flight controls engineer, I wrote a couple articles about lessons that transfer to software: Safe Systems from Unreliable Parts https://www.digitalmars.com/articles/b39.html https://www.digitalmars.com/articles/b39.html Designing Safe Software Systems Part 2 https://www.digitalmars.com/articles/b40.html https://www.digitalmars.com/articles/b40.html

mips_r4300i 3y ago
Good points. Embedded systems deal with many of those. It made me think of a funny story that causes me to pay closer attention to things like this: Some time ago I shipped a product running an RTOS which unfortunately had a subtle scheduler bug where it would randomly crash periodically. The bug was pretty rare (I thought), only affecting part of the system, and reproducing the bug took several days each time. In my infinite genius, rather than waste weeks of valuable time up to release, I set up the watchdog timer on the processor to write a crash dump and silently reboot. A user would maybe see a few seconds of delayed input and everything would come back up shortly. Unfortunately, I had accidentally set the watchdog clock divider the wrong way, resulting in the watchdog not activating for over 17 hours after a hang! The bug became much more widely noticeable after the product was released, and only by sheer luck, many people never noticed it. I eventually fixed the scheduler bug in an update, but the useless watchdog configuration was set in stone and not fixable. Taught me to never assume a rare bug would stay rare when many tens of thousands of people use something in the field.

vunderba 3y ago

When I started working for more consumer facing application developing companies, I tried to adopt the software developers equivalent of "if you're the developer of a new experimental plane, you're the first to go up in the said plane."

deathanatos 3y ago

It's a lot of good advice, but IME the next step is "but how do I actually do this?" A lot of the difficultly boils down to an inverse NIH syndrome: we outsource monitoring and alerting … and the systems out there are quite frankly pretty terrible. We struggle with alert routing, because alert routing should really take a function that takes alert data in and figures out what to do with it … but Pagerduty doesn't support that. Datadog (monitoring) struggles (struggles) with sane units, and IME with aliasing. DD will also alert on things that … don't match the alert criteria? (We've still not figured that one out.) “Aviate, Navigate, Communicate” definitely is a good idea, but let me know if you figure out how to teach people to communicate. Many of my coworkers lack basic Internet etiquette. (And I'm pretty sure "netiquette" died a long time ago.) The Swiss Cheese model isn't just about having layers to prevent failures. The inverse axiom is where the fun starts: the only failures you see, by definition, are the ones that go through all the holes in the cheese simultaneously. If they didn't, then by definition, a layer of swiss has stopped the outage. That means "how can this be? like n different things would have to be going wrong, all at the same time" isn't really an out in an outage: yes, by definition! This is too, of course, assuming you know what holes are in your cheese, and often, the cheese is much holier than people seem to think it is. I'm always going to hard disagree with runbooks, though. Most failures are of the "it's a bug" variety: there is no possible way to write the runbook for them. If you can write a runbook, that means you're aware of the bug: fix the bug, instead. The rest is bugs you're unaware of, and to write a runbook would thus require clairvoyance. (There are limited exceptions to this: sometimes you cannot fix the bug: e.g., if the bug lies in a vendor's software and the vendor refuses to do anything about it¹, then you're just screwed, and have to write down the next best work around, particularly if any workaround is hard to automate. There are other pressures, like PMs who don't give devs the time to fix bugs, but in general runbooks are a drag on productivity, as they're manual processes you're following in lieu of a working system. Be pragmatic about when you take them on (if you can). > Have a “Ubiquitous language” This one, this one is the real gem. I beg of you, please, do this. A solid ontology prevents bugs. This gets back to the "teach communication" problem, though. I work with devs who seem to derive pleasure from inventing new terms to describe things that already have terms. Communicating with them is a never ending game of grabbing my crystal ball and decoding WTF it is they're talking about. Also, I know the NATO alphabet (I'm not military/aviation). It is incredibly useful, and takes like 20-40 minutes of attempting to memorize it to get it. It is mind boggling that customer support reps do not learn this, given how shallow the barrier to entry is. (They could probably get away with like, 20 minutes of memorization & then learn the rest just via sink-or-swim.) (I also have what I call malicious-NATO: "C, as in sea", "Q, as in cue", "I, as in eye", "R, as in are", U, as in "you", "Y, as in why") > Don’t write code when you are tired. Yeah, don't: https://www.cdc.gov/niosh/emres/longhourstraining/impaired.html https://www.cdc.gov/niosh/emres/longhourstraining/impaired.h... And yet I regularly encounter orgs or people suggesting that deployments should occur well past the 0.05% BAC equivalent mark. "Unlimited PTO" … until everyone inevitably desires Christmas off and then push comes to shove. Some of this intertwines with common PM failure modes, too: I have, any number of times, been pressed for time estimates on projects where we don't have a good time estimate because there are two many unknowns in the project. (Typically because whomever is PM … really hasn't done their job in the first place of having even the foggiest understanding of what's actually involved, inevitably because the PM is non-technical. Having seen a computer is not technical.) When the work is then broken out and estimates assigned to the broken out form, the total estimate is rejected, because PMs/management don't like the number. Then inevitably a date is chosen at random by management. (And the number of times I've had a Saturday chosen is absurd, too.) And then the deadline is missed. Sometimes, projects skip right to the arbitrary deadline step, which at least cuts out some pointless debate about, yes, what you're proposing really is that complicated. That's stressful, PMs. ¹ cough Azure cough excuse me.

r2on3nge 3y ago

This is so fascinating! Continuing becoming better and better everyday.