Hacker News new | past | comments | ask | show | jobs | submit
The assumption that moving slower and more bureaucratically increases safety and reliability is one of the most harmful myths out there.
The problem is that in the FAA's domain, there are legitimately situations where bureaucracy is indispensable. For example, they just issued an AD to require inspections of a few specific bolts on early production 787s because Boeing thinks they MAY have bolted the wings on with incorrectly sized shims, which over a decade MAY contribute to accelerated fatigue on these parts. Not a single plane has crashed but this kind of thing has caused other planes to crash in the past.

These airplanes are flying all over the world, the inspections need ultrasonic data, and the FAA has to validate that all of them are done. Even identifying this issue required lots of bureaucracy.

Multiply that by the number of airplanes and airplane models and it's easy to see why they move so slowly: when you are putting millions of people in the air each day, enforcing absurdly specific rules with an iron fist requires a monster of a bureaucracy.

But moving faster and without accountability is generally worse.

In a perfect world, we would move at a steady pace, as to keep up with the world but without rushing, and people would be accountable without a heavy bureaucratic processes.

Unfortunately, that's not how it works in practice, at least not for long, so between the two, we usually favor the slow and bureaucratic process when safety and reliability matter.

In fact, it's created a bunch of risks. Like the fact that nobody manufacturers floppy disks or floppy disk readers anymore.

I can understand not changing a system for change sake, but the floppy disk has been obsolete for nearly 20 years now. It's been hard to find a floppy disk reader for the last 10 years. Going so slow that you can't respond to that change is far FAR too slow.

loading story #50396248
loading story #50396441
loading story #50396466
loading story #50398979
loading story #50396135
Creating a rigorous process to ensure safety will create somewhat of a bureaucracy.

But creating a bureaucracy doesn't mean you've created a rigorous process to ensure safety.

Yup, it can create a situation where you have a huge incentive towards workarounds and hacky fixes because doing it properly incurs huge costs. This is especially bad when a fundamentally quite bad design makes it through certification (most processes don't really prevent this).
Presumably such a confident assertion is based on sufficient actual experience with slower safety protocols such that you can state, positively, that faster-moving processes produce safer, human-life critical, systems... ?
You really, really need to work in industrials controls before your opinion carries weight on this - there are plenty of 40 year old systems humming along keeping the world turning that are bulletproof reliable.

'Move fast and break things' is fine when the result of failure is someone failing to make a billion dollars at their IPO. It's not acceptable in the world where failure means dams break, reactors go supercritical, planes collide, or other similarly apocalyptic scenarios.

Yes - but those examples don't all have the same risk modalities. With dams and reactors, most failure variables can be permanently contained by initial system design/engineering and construction quality, continually inspected surroundings and internals, and physics certainty. Human inputs are limited and daily inspection matters, but any momentary error or lapse of operator attention won't result in instant destruction. You have hours and days with Dams, minutes and hours with reactors. In aviation it only takes a split second.

Aviation involves constant unpredictable human inputs and physical states. Hundreds of vehicles, not installations designed to have as few moving parts as possible. It is not yet solved, the status quo merely has a societally tolerable death rate. There can be new sensor hardware, more safety redundancies, and info synthesis/notification interfaces that are currently blocked by old hardware bottlenecks. Controller and pilot time and attention is limited, and it can be wasted less.

loading story #50399794
I feel a bit weird that I'm fairly certain that I read this discussion a while ago, in another post...