Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Trying to become a better developer by learning more about aviation

medium.com

Post reply on HN
Print view View original

61–70 of 92 posts

Re: Trying to become a better developer by learning more about aviation

#61

Post by resonious »

jacquesm wrote: post #50
Animats wrote: post #20

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 off…

> There are not "bugs". There are "defects". Priceless, I've been trying make that point for years but nobody seems to want to listen.

What's the difference? I'm not sure how this renaming would change my behavior.

Re: Trying to become a better developer by learning more about aviation

#62

Post by photochemsyn »

jacquesm wrote: post #50
Animats wrote: post #20

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 off…

> There are not "bugs". There are "defects". Priceless, I've been trying make that point for years but nobody seems to want to listen.

A defective device in my mind would have some obviously fatal flaw - it wouldn't even start up, parts would be broken and dangling off, etc. QC immediately rejects it and it doesn't get incorporated into more complex systems.

A buggy device is much worse for any critical application - it appears to work under inspection, and even limited testing, but 1% of the time it develops some fatal data race condition that causes it to fail erratically and cause havoc, e.g. the Therac-25.

So buggy is a subset of defective but it's even worse?

Re: Trying to become a better developer by learning more about aviation

#63

Post by psunavy03 »

gbacon wrote: post #14
KolmogorovComp wrote: post #9

> 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

Don't forget their cousins "tree" and "fife" — or the overpronunciation of Papa as /papà/.

No one actually uses "tree" and "fife."

Re: Trying to become a better developer by learning more about aviation

#64

Post by ohdannyboy »

evil-olive wrote: post #17
eschneider wrote: post #2

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.

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/ 1: https://www.reddit.com/r/AdmiralCloudberg/comments/e6n80m/pl... 2: ht…

+1 for Mentour, being a commercial pilot himself his insights are fantastic.

Re: Trying to become a better developer by learning more about aviation

#65

Post by SoftTalker »

ryandrake wrote: post #43
syndicatedjelly wrote: post #33

Earlier quoted context omitted.

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

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!

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.

Re: Trying to become a better developer by learning more about aviation

#66

Post by jacquesm »

resonious wrote: post #61
jacquesm wrote: post #50

Earlier quoted context omitted.

> There are not "bugs". There are "defects". Priceless, I've been trying make that point for years but nobody seems to want to listen.

What's the difference? I'm not sure how this renaming would change my behavior.

The difference is that a bug implies that it is an outside influence, a defect is something that has to do with making the thing in the first place. A bug you can see as happenstance, a defect implies liability. Huge difference.

Re: Trying to become a better developer by learning more about aviation

#67

Post by cromulent »

SoftTalker wrote: post #25
Animats wrote: post #20

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 off…

I like the term "defect" it's more accurate than "bug."

Tester at work calls them “defects”. Mostly they are “test findings” resulting from hallucinated specifications that don’t exist except in his mind, or misunderstandings from him not reading the documentation. Or data problems. It’s annoying having them called “bugs” let alone “defects”.

Re: Trying to become a better developer by learning more about aviation

#68

Post by zmgsabst »

photochemsyn wrote: post #62
jacquesm wrote: post #50

Earlier quoted context omitted.

> There are not "bugs". There are "defects". Priceless, I've been trying make that point for years but nobody seems to want to listen.

A defective device in my mind would have some obviously fatal flaw - it wouldn't even start up, parts would be broken and dangling off, etc. QC immediately rejects it and it doesn't get incorporated into more complex systems. A buggy device is much worse for any critical application - it appears to work under inspection, and even limited testing, but 1% of the time it develops some fatal data race condition that caus…

Defects in, eg, pressure vessels can be hard to spot and then suddenly explode when the product is used — sometimes only after a period of seemingly normal operation.

They’re still defects.

Re: Trying to become a better developer by learning more about aviation

#69

Post by m463 »

gbacon wrote: post #13

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 appli…

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.

Re: Trying to become a better developer by learning more about aviation

#70

Post by tonyarkles »

SoftTalker wrote: post #65
ryandrake wrote: post #43

Earlier quoted context omitted.

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!

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.

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.
Post reply on HN