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

Software Engineering Lessons from Aviation

riceo.me

Post reply on HN
Print view View original

11–20 of 56 posts

Re: Software Engineering Lessons from Aviation

#11

Post by ken »

jefffoster wrote: post #3

I think there's a lot to learn from the aviation industry. I did a talk at my companies internal conference on this (turned into words at https://medium.com/ingeniouslysimple/why-dont-planes-crash-1... ). For me it's the mindset that differs. Too often as software engineers we find a bug and just fix it. Aviation goes a step deeper and finds the environment that created the bug and stops that. Unfortunately, the rece…

There are a handful of highly respected books that everyone knows software engineers should read, like "The Mythical Man-Month" and "Peopleware". Yet whenever I read one of these, I found I learned very little. Everything in them was obvious -- to those who are 'in the trenches'. What we need is a way to get managers to read these, and take them to heart. Even when my manager had a copy of the book sitting on their desk, they rarely had read it, and they absolutely never followed its advice.

(When pushed, they might say "That was a groundbreaking book, for its day, but the industry moved on." Now we've got open floor plans, and AGILE SCRUM, and free snacks ... and also no evidence these are an improvement to the software development process, but never mind.)

This aviation mindset you refer to is the same way. I can't tell you how many times this happened to me:

- User clicks a button, and it doesn't do what it says it should.

- A bug is filed, and assigned to me.

- I investigate, and find the problem. I start preparing a fix.

- Manager comes by to pester me. "Why isn't this button fixed? Shouldn't that have been a quick fix?" We played Planning Poker last week and everybody else who isn't working on it agreed it should only be a 1!

- See, we're computing this value incorrectly, and I grepped the codebase and it turns out we're also doing it wrong in 7 other places, which causes...

- "The customer wants this one button fixed. Don't worry about the others. Don't worry about testing, or cleaning up, or documenting why the mistake was made or how it should have been done. Those aren't on this milestone. Just fix this one button and move on. We need you working on the new features we promised our customers this month..."

Modern software development is a circus of improperly aligned incentives.

Re: Software Engineering Lessons from Aviation

#12

Post by jasode »

Kurtz79 wrote: post #9
jasode wrote: post #8

Earlier quoted context omitted.

>as software engineers we find a bug and just fix it. [...] Unfortunately, the recent 737 MAX incidents seem to have changed this. I think there's some nuance about MCAS that's lost in all the media reports. As far as I understand, the MCAS software didn't have a "bug" in the sense we programmers typically think of. (E.g. Mars Climate Orbiter's software programmed with incorrect units-of-measure.[0]) Instead, the MCA…

"If the software was changed to reconcile 2 sensors, it would then lead to a new "AOA Disagree" indicator which would raise doubts to the FAA that Boeing could just give pilots a simple iPad training orientation instead of expensive flight-sim training." I always liked this quote from the "Mythical Man-Month": “Never go to sea with two chronometers, take one or three”. https://blog.ipspace.net/2017/01/never-take-two-…

>I always liked this quote from the "Mythical Man-Month": “Never go to sea with two chronometers, take one or three”.

(I can't tell if you're making a side comment or specifically replying to the categorization of "software bug".)

Yes, the 737 MAX only has 2 AOA sensors instead of 3 like Airbus A320. This is a physical design of sensors mounted on the airframe. But this aerospace engineering design detail seems outside the scope of assigning blame to software programmers writing code. (There isn't a software coding methodology that makes a 3rd AOA sensor appear.)

Re: Software Engineering Lessons from Aviation

#13

Post by asn1parse »

ken wrote: post #11
jefffoster wrote: post #3

I think there's a lot to learn from the aviation industry. I did a talk at my companies internal conference on this (turned into words at https://medium.com/ingeniouslysimple/why-dont-planes-crash-1... ). For me it's the mindset that differs. Too often as software engineers we find a bug and just fix it. Aviation goes a step deeper and finds the environment that created the bug and stops that. Unfortunately, the rece…

There are a handful of highly respected books that everyone knows software engineers should read, like "The Mythical Man-Month" and "Peopleware". Yet whenever I read one of these, I found I learned very little. Everything in them was obvious -- to those who are 'in the trenches'. What we need is a way to get managers to read these, and take them to heart. Even when my manager had a copy of the book sitting on their d…

When they did the open space with free snacks I told them I was never coming into the office again. I pointed out that I got sick roughly 3 times a year from just being forced to spend time in that hazardous office. And I then I sealed it by telling them that they will get 2 extra hours of work out of me each day plus all the CO2 I wouldnt be pumping into the atmosphere each day when I drive there on the perilous freeways with all the other pissed off people on the road. And they bought it. This was 2012. Ffw to 2019, I still work at home for the same company. I never get sick, I dont have to deal with any of the toxic culture stuff at work, and I buy and consume my own snacks, the ones I want to eat. I agree, it's a circus and it's a lot easier to manage from a distance.

Re: Software Engineering Lessons from Aviation

#14

Post by mixmastamyk »

asn1parse wrote: post #13
ken wrote: post #11

Earlier quoted context omitted.

There are a handful of highly respected books that everyone knows software engineers should read, like "The Mythical Man-Month" and "Peopleware". Yet whenever I read one of these, I found I learned very little. Everything in them was obvious -- to those who are 'in the trenches'. What we need is a way to get managers to read these, and take them to heart. Even when my manager had a copy of the book sitting on their d…

When they did the open space with free snacks I told them I was never coming into the office again. I pointed out that I got sick roughly 3 times a year from just being forced to spend time in that hazardous office. And I then I sealed it by telling them that they will get 2 extra hours of work out of me each day plus all the CO2 I wouldnt be pumping into the atmosphere each day when I drive there on the perilous fre…

Hate open offices too, but take some Vitamin D3 if you getting sick all the time. Exposure to pathogens is what exercises the immune system and is a necessary evil.

Re: Software Engineering Lessons from Aviation

#15

Post by mixmastamyk »

ken wrote: post #11
jefffoster wrote: post #3

I think there's a lot to learn from the aviation industry. I did a talk at my companies internal conference on this (turned into words at https://medium.com/ingeniouslysimple/why-dont-planes-crash-1... ). For me it's the mindset that differs. Too often as software engineers we find a bug and just fix it. Aviation goes a step deeper and finds the environment that created the bug and stops that. Unfortunately, the rece…

There are a handful of highly respected books that everyone knows software engineers should read, like "The Mythical Man-Month" and "Peopleware". Yet whenever I read one of these, I found I learned very little. Everything in them was obvious -- to those who are 'in the trenches'. What we need is a way to get managers to read these, and take them to heart. Even when my manager had a copy of the book sitting on their d…

I know few of us want to become managers, but when you find a harmful one, it's time to take on that responsibility.

Re: Software Engineering Lessons from Aviation

#16

Post by billfruit »

Though article isn't about software development in the aviation industry, a few thoughts on that:

The industry is really slow to change its practices and tools. Like the use of C for most software, I do feel a more safer language out to be preferred.

Use of 1553 bus for inter device communication, the bus and protocol aren't general, it is very opinionated/rigid about the manner in which communication should happen. And the hardware parts for it are horrendously expensive compared to most ethernet, IP equipment. There is an aviation ethernet standard, but adoption of it has been slow.

Re: Software Engineering Lessons from Aviation

#17

Post by myl »

"...plenty of episodes of Mayday/Air Crash Investigation available on Youtube too. (Be warned though, all doomed flights take off from one of the busiest airports in the world .)" Great show. Comment is spot on, and don't forget "investigators were under extreme pressure".

Re: Software Engineering Lessons from Aviation

#18

Post by Kurtz79 »

jasode wrote: post #12
Kurtz79 wrote: post #9

Earlier quoted context omitted.

"If the software was changed to reconcile 2 sensors, it would then lead to a new "AOA Disagree" indicator which would raise doubts to the FAA that Boeing could just give pilots a simple iPad training orientation instead of expensive flight-sim training." I always liked this quote from the "Mythical Man-Month": “Never go to sea with two chronometers, take one or three”. https://blog.ipspace.net/2017/01/never-take-two-…

>I always liked this quote from the "Mythical Man-Month": “Never go to sea with two chronometers, take one or three”. (I can't tell if you're making a side comment or specifically replying to the categorization of "software bug".) Yes, the 737 MAX only has 2 AOA sensors instead of 3 like Airbus A320. This is a physical design of sensors mounted on the airframe. But this aerospace engineering design detail seems outsi…

It was mostly a side comment, but it seemed appropriate in this context.

For such an important system, I would think that a single instance would be too little (single point of failure: even in less mission critical system it wouldn't be allowed), while using two you would not be able to resolve a reading conflict between them (which is the point of the quote), so three is probably a reasonable number.

Even if applied to design and not to software programming, the concept is still sound. The point was what the quote meant, not its source.

Re: Software Engineering Lessons from Aviation

#19

Post by sn »

Checklists and written procedures are very important. One of the earlier things I did when coming into my company was create a written procedure for software upgrades until we had time to automate it with ansible.

One thing I have not had very good discipline about is I want to use checklists both for code submitted for review and when I'm doing reviews. Lint checkers etc. can only go so far.

If anyone has published checklists for code reviews I'd be curious to see them. This one seems reasonable: https://www.liberty.edu/media/1414/%5B6401%5Dcode_review_che... though I'd add concurrency to the list.

Post reply on HN