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

Software engineering lessons from RCAs of greatest disasters

anoopdixith.com

Post reply on HN
Print view View original

111–120 of 150 posts

Re: Software engineering lessons from RCAs of greatest disasters

#111

Post by datadrivenangel »

yafbum wrote: post #45
seanhunter wrote: post #38

One of my favourites that I ever heard about was from a friend of mine who used to work on safety-critical systems in defense applications. He told me fighter jets have a safety system that disables the weapons systems if a (weight) load is detected on the landing gear so that if the plane is on the ground and the pilot bumps the wrong button they don't accidentally blow up their own airbase[1]. So anyway when the Eu…

> this cost several millions to redeploy the (one-line) fix to actually check the weight from the sensor was less than the threshold Well maybe this is the other, compounding problem. Engineering complex machines with such a high cost of bugfix deployment seems like a big issue. It's funny that as an industry we now know how to safely deploy software updates to hundreds of millions of phones, with security checks, si…

a few million dollars works out to a surprisingly small amount of time when you add overhead.

Call the bug fix a development team of 20 people taking 3 months end to end from bug discovery to fix deployment. You'll probably have twice that much people time again in project management and communication overhead (1:2 ratio of dev time to communication overhead is actually amazing in defense contexts). Assume total cost per person of 200k per year (after factoring in benefits, overhead, and pork), so 60 people * 3 months * $200k/12 months = 3,000,000 USD.

It takes a lot of people to build an aircraft.

Re: Software engineering lessons from RCAs of greatest disasters

#113

Post by mrguyorama »

kakwa_ wrote: post #103
mrguyorama wrote: post #95

Earlier quoted context omitted.

A mark 14 torpedo actually sinking something? What a bad stroke of luck!

The Mark 14 ended-up being a really good torpedo by the end of WWII. It even remained in service until the 80ies. In truth, and going back to this subject, the Mark 14 debacle highlights the need for a good and unbiased QA. This also holds true for software engineering.

My understanding is the BeuOrd (or BeuShip? I don't remember which) "didn't want to waste money on testing it", so instead we wasted hundreds of them fired at japanese shipping that didn't even impact their target, or never had a hope of detonating.

Remember these kind of things next time someone pushes for move fast and break things in the name of efficiency and speed. Slow is fast.

Re: Software engineering lessons from RCAs of greatest disasters

#114

Post by mrguyorama »

jacquesm wrote: post #110
mrguyorama wrote: post #101

Earlier quoted context omitted.

There are two useful lessons from the Titanic that can apply to software: 1) Marketing that you are super duper and special is meaningless if you've actually built something terrible (the Titanic was not even remotely as unsinkable as claimed, with "water tight" compartments that weren't actually watertight) 2) When people below you tell you "hey we are in danger", listen to them. Don't do things that are obviously d…

Good stuff, thank you. This is useful, and it (2) ties into the Challenger disaster as well.

The one hangup with "Listen to people warning you" is that they produce enough false positives as to create a boy who cried wolf effect for some managers.

Re: Software engineering lessons from RCAs of greatest disasters

#115

Post by Two4 »

nvy wrote: post #90
yafbum wrote: post #45

Earlier quoted context omitted.

> this cost several millions to redeploy the (one-line) fix to actually check the weight from the sensor was less than the threshold Well maybe this is the other, compounding problem. Engineering complex machines with such a high cost of bugfix deployment seems like a big issue. It's funny that as an industry we now know how to safely deploy software updates to hundreds of millions of phones, with security checks, si…

>It's funny that as an industry we now know how to safely deploy software updates to hundreds of millions of phones, with security checks, signed firmwares, etc, but doing that on applications with a super high unit price tag seems out of reach A bunch of JavaScript dudebros yeeting code out into the ether is not at all comparable to deploying avionics software to a fighter jet. Give your head a shake.

I don't think they're referring to dudebros' js, they're referring to systems software and the ability to deliver relatively secure updates over insecure channels. I've even delivered a signed firmware update to a microprocessor in a goddamn washing machine over UART. Why can't we do this for a jet?

Re: Software engineering lessons from RCAs of greatest disasters

#116

Post by Balooga »

the_sleaze9 wrote: post #92
digging wrote: post #59

Earlier quoted context omitted.

This makes no sense and is difficult to even respond to coherently. > It's funny that as an industry we now know how to safely deploy software updates to hundreds of millions of phones, with security checks, signed firmwares, etc, Either you're completely wrong, because we "as an industry" still push bugs and security flaws, or you're comparing two completely different things. > doing that on applications with a supe…

I would generally pass this comment by, but it's just so distastefully hostile because you totally missed the point. GP's comment was expressing sardonic disbelief that a modern jet wouldn't be able to receive remote software updates, considering it's so ubiquitous and reliable in other fields, even those with much, much lower costs. Not that developers don't release faults.

Imagine remotely bricking a fleet of fighter jets.

https://news.ycombinator.com/item?id=35983866

Re: Software engineering lessons from RCAs of greatest disasters

#117

Post by tialaramex »

seanhunter wrote: post #38

One of my favourites that I ever heard about was from a friend of mine who used to work on safety-critical systems in defense applications. He told me fighter jets have a safety system that disables the weapons systems if a (weight) load is detected on the landing gear so that if the plane is on the ground and the pilot bumps the wrong button they don't accidentally blow up their own airbase[1]. So anyway when the Eu…

> if a (weight) load is detected on the landing gear

This state "weight on wheels" is used in a lot of other functionality, not just on military aircraft, as the hard stop for things that don't make sense if we're not airborne. So that makes sense (albeit obviously somebody needed to actually write this function)

Most obviously the gear retraction is disabled on planes which have retractable landing gear.

Re: Software engineering lessons from RCAs of greatest disasters

#118

Post by jacquesm »

mrguyorama wrote: post #114
jacquesm wrote: post #110

Earlier quoted context omitted.

Good stuff, thank you. This is useful, and it (2) ties into the Challenger disaster as well.

The one hangup with "Listen to people warning you" is that they produce enough false positives as to create a boy who cried wolf effect for some managers.

Yes, that's true. So the hard part is to know who is alarmist and who actually has a point. In the case of NASA the ignoring bit seemed to be pretty wilful. By the time multiple engineers warn you that this is not a good idea and you push on anyway I think you are out of excuses. Single warnings not backed up by data can probably be ignored.

Re: Software engineering lessons from RCAs of greatest disasters

#119

Post by jacquesm »

mrguyorama wrote: post #113
kakwa_ wrote: post #103

Earlier quoted context omitted.

The Mark 14 ended-up being a really good torpedo by the end of WWII. It even remained in service until the 80ies. In truth, and going back to this subject, the Mark 14 debacle highlights the need for a good and unbiased QA. This also holds true for software engineering.

My understanding is the BeuOrd (or BeuShip? I don't remember which) "didn't want to waste money on testing it", so instead we wasted hundreds of them fired at japanese shipping that didn't even impact their target, or never had a hope of detonating. Remember these kind of things next time someone pushes for move fast and break things in the name of efficiency and speed. Slow is fast.

In NL folklore this is codified as 'the longest road is often the shortest'.

Re: Software engineering lessons from RCAs of greatest disasters

#120

Post by jacquesm »

digging wrote: post #106
the_sleaze9 wrote: post #92

Earlier quoted context omitted.

I would generally pass this comment by, but it's just so distastefully hostile because you totally missed the point. GP's comment was expressing sardonic disbelief that a modern jet wouldn't be able to receive remote software updates, considering it's so ubiquitous and reliable in other fields, even those with much, much lower costs. Not that developers don't release faults.

Ahh, then I did misread it entirely. Thanks for stopping by to call me out. It's still probably not a matter of capability... I wouldn't be so cavalier about software updates on my phone if it was holding me thousands of feet above the ground at the time.

I already commented on this elsewhere but I came across a company that did OTA updates on a control box in vehicles without checking if the vehicle was in motion or not. And it didn't even really surprise me, it was just one of those things that came up when prepping for that job from a risk assessment. They never even thought of it.
Post reply on HN