Hacker News Reader

Comment by fefe23 | Hacker News Reader

I sure hope OP does not write code for medical devices, aerospace or self-driving cars, reactor or heavy machinery controls or anything else where lives are at stake.

Your current product may be a free TV series reminder service where you can go full YOLO. Then feel free to follow OP's advice. Otherwise, I recommend against it.

View on HN

To temper this a bit: thankfully, all those industries are full of regulation and V-model and piles of documentation (for every line of code, multiple lines of other stuff on paper). Serious customers won't touch your product if you don't have a certified quality management system that fits The Standard.

I work in one of these industries -- I don't see much safety-critical engineering content on HN, and I think it's fair enough that it's glossed over. I agree that you can't move fast and break things when those things can hurt, or physically are, people.

> aerospace

I have no idea what the code culture looks like at Boeing, but it's possible that if engineers had more skin in the game, the 737 MAX problem wouldn't have happened. When you depend on a QA team, it's easy to throw code that compiles over the fence and say it's someone else's problem, now.

The 737max problem had nothing to do with software bugs. The software worked exactly as specified, it's the higher-level system design which was wrong.

Could you elaborate?

Not OP, but I have worked in e-commerce / web services and currently work in safety critical software.

This article does not address safety critical software engineering since some of the points would not work in safety critical software:

"QA Gates Make Quality Worse" - In safety critical software development it would be crazy to negligent to not have QA gates. For example, if the safety critical software is running a critical aircraft control system would you feel comfortable getting on the airplane if there were no QA gates?

"Things Will Always Break" - When things break in safety critical software, it is Boeing 737 Max-bad or worse. People die. Things catch fire and explode. You can not just "roll back" to the previous version of the software and restart the server because often the damage is already done and there is nothing left to restart.

In safety critical environment, you'd better have done your FMECA and designed the system to be "fail-safe". The problem with the 737-Max is that it wasn't.

Fail-safe doesn't mean "no failures" or "no breakages". It means that when they happen (and they will), the system fails in a way that is safe.

QA "gates" in terms of the "throw it over the wall to QA and they will test it in all possible scenarios to ensure quality" is different to QA "gates" that are "throw all of the failure modes that have been identified as dangerous and ensure that the system fails in a safe manner."

That can be part of a CI/CD pipeline in exactly the same way as in the web/cloud world, including generating all of the necessary documentation and evidence for ISO etc standards.

"When A Fail-Safe System Fails, It Fails By Failing To Fail Safe"

Same here. In a lot of areas it's feasible to roll out something that works to a reasonable degree and then respond to bug reports and fix them quickly. I now work in medical devices and it would be hard to explain that after somebody has been killed by a pacemaker that we are fixing the bug now.

I would hope to anyone reading that it would be blindingly obvious that the Continuous Delivery paradigm of "testing in production" doesn't apply to fucking aircraft. Just to be clear.

Got it, thanks! Makes perfect sense to me (to have those assurances).

Reply on news.ycombinator.com