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

91–100 of 150 posts

Re: Software engineering lessons from RCAs of greatest disasters

#91

Post by mrguyorama »

zvmaz wrote: post #72
LeonenTheDK wrote: post #68

Earlier quoted context omitted.

This is exactly why I support "engineer" being a protected term, like Doctor. It should tell you that a certain level of training and qualification has been met, to the point that the engineer is responsible and accountable for the work they do and sign off on. Especially for things that affect safety. Many software engineers these days are often flying by the seat of their pants, moving quickly and breaking things.…

Are all "engineers" trained on human error, safety principles, and the like? The failures described in the article are precisely not software failures.

Yes? Most engineering programs (it might even be an accreditation requirement) involve ethics classes and learning from past failures.

My CS degree program required an ethics class and discussed things like the CFAA and famous cases like Therac-25, but nobody took it seriously because STEM majors think they are god's gift to an irrational world.

Re: Software engineering lessons from RCAs of greatest disasters

#92

Post by the_sleaze9 »

digging wrote: post #59
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…

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.

Re: Software engineering lessons from RCAs of greatest disasters

#93

Post by sanderjd »

fredley wrote: post #67
RetroTechie wrote: post #63

Earlier quoted context omitted.

In terms of engineering (QC, processes etc), modern day software industry is worse than almost any other industry out there. :-( And no, just plain complexity or fast-moving environment, is a factor but not the issue. It's that steps are skipped which are not skipped in other branches of engineering (eg. continous improvement of processes, learning from mistakes & implementing those. In software land: same mistakes m…

In any other field of engineering, the engineers are all trained and qualified. In software 'engineering', not so much.

That training and qualification is only as good as the processes and standards being trained for and qualified on. We don't have those processes and standards to train against (and frankly I'm not convinced we should or even can) for generic "software engineers". I have a number of friends who are PEs, and it isn't the training and certification process that differentiates their work from mine, it is that there are very clear standards for how you engineer a safe structure or machine. But I contend that there is not a way to write such standards for "software". It's just too broad a category of thing. Writing control software for physical systems is just very different from writing a UX-driven web application. It would be odd and wasteful to have the same standards for both things.

I do think qualification would make sense for more narrow swathes of the "software engineering" practice. For instance, "Automotive Control Software Engineer", etc.

Re: Software engineering lessons from RCAs of greatest disasters

#94

Post by mrguyorama »

zenkat wrote: post #51
hliyan wrote: post #11

I think the software industry itself has accumulated enough bugs over the past few decades. E.g. F-22 navigation system core dumps when crossing the international date line: https://medium.com/alfonsofuggetta-it/software-bug-halts-f-2... Loss of Mars probe due to metric-imperial conversion error I've a few of these myself (e.g. a misplaced decimal that made $12mil into $120mil), but sadly cannot devulge details.

Does anyone have a similar compendium specifically for software engineering disasters? Not of nasty bugs like the F-22 -- those are fun stories, but they don't really illustrate the systemic failures that led to the bug being deployed in the first place. Much more interested in systemic cultural/practice/process factors that led to a disaster.

Find and take a CS ethics class.

Re: Software engineering lessons from RCAs of greatest disasters

#95

Post by mrguyorama »

mwcremer wrote: post #89
JackFr wrote: post #57

Earlier quoted context omitted.

Torpedoes typically have an inertial switch which disarms them if they turn 180 degrees, so they don't accidentally hit their source. When a torpedo accidentally arms and activates on board a submarine (hot running) the emergency procedure is to immediately turn the sub around 180 degrees to disarm the torpedo.

Lest someone think this is purely hypothetical: https://en.wikipedia.org/wiki/USS_Tang_(SS-306)

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

Re: Software engineering lessons from RCAs of greatest disasters

#96

Post by WalterBright »

seanhunter wrote: post #46
MisterTea wrote: post #43

Earlier quoted context omitted.

> weird version of ADA Spark: https://en.wikipedia.org/wiki/SPARK_(programming_language) And it's Ada not ADA which makes me think of the Americans with Disabilities Act.

Aah thank you on both counts yes. One interesting feature he told me about is they wrote a "reverse compiler" that would take Spark code and turn it into the associated formal (Z) spec so they could compare that to the actual Z spec to prove they were the same. Kind of nifty.

Sounds like Tranfor which would convert FORTRAN code to flowcharts, because government contracts required flowcharts.

Re: Software engineering lessons from RCAs of greatest disasters

#97

Post by WalterBright »

It isn't just software.

The Deepwater Horizon was the result of multiple single points of failure, that zippered to catastrophe. Each of those single points of failure could have been snipped at little to no cost

The same with the Fukushima disaster. For example, venting the excess hydrogen into the building, where it could accumulate until a random spark.

Re: Software engineering lessons from RCAs of greatest disasters

#98

Post by feldrim »

GreenVulpine wrote: post #31
Exuma wrote: post #15

Earlier quoted context omitted.

My worst bug was a typo in a single line of html that removed 3DS protection from many millions of dollars of credit card payments

You could call that a feature making payments easier for customers! All 3DS does is protect the banks by inconveniencing consumers since banks are responsible for fraud.

It's mostly the payment processor. It may or may not be the bank itself.

Re: Software engineering lessons from RCAs of greatest disasters

#99

Post by jacquesm »

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…

> Yes this means that scene from the cheesy action movie (can't remember which one) where Arnold Schwartzenegger finds himself on the ground in the cockpit of a russian plane and proceeds to blow up all the badguys while on the ground couldn't happen in real life.

I think you meant "Tomorrow Never Dies" and the actor was Pierce Brosnan. Took me forever to find that, is it the right one?

Re: Software engineering lessons from RCAs of greatest disasters

#100

Post by jacquesm »

masfuerte wrote: post #78

There is or was an old-school website called something like "Byzantine failures" that had case studies of bizarre failures from many engineering fields. It was entertaining but I am unable to find it now. Does anyone know it?

I think you're talking about Risks Digest.

http://catless.ncl.ac.uk/Risks/

It's very much old-school.

Post reply on HN