Hacker News Reader

Comment by lectrick | Hacker News Reader

I have a nagging (intuition? feeling?) that software safety/reliability/security needs are going to explode soon (because unreliabilities multiply in non-resilient systems interacting with each other) and that these are simply foreshocks.

(yeah, I know security is already a huge deal, but as we come to trust software systems more and more, the safety/reliability factor will come more into play)

EDIT: This is also part of the reason I've been learning Elixir (http://elixir-lang.org/) since it's based on the highly-resilient Erlang and is designed to embrace failure. This was also informed by me reading Nassim Taleb's book "Antifragile" as well as "Thinking in Systems: A Primer" by the (late) Donella Meadows.

View on HN

Nancy Leveson's been saying that for decades: http://www.amazon.com/Safeware-Computers-Nancy-G-Leveson/dp/...

I doubt it. Nobody wants to pay for that.

You might be right, unfortunately. If it's cheaper to buy insurance that will cover the (expected) losses caused by outages, most organizations will choose to do that instead of making the software more failure-resistant. The problem is that insurance only works well for isolated incidents, but a software failure can cause a cascading failure with a huge impact. Insurance companies generally aren't prepared for that and don't have the resources to pay out to everyone.

But aren't the insurance companies smart enough to figure this out and start correcting their rates to be much higher?And if they actually have their acts together, wouldn't those same insurance companies start insisting on basic audits of their client's systems?

I actually don't know about this stuff, so any correction of my thoughts is appreciated.

> But aren't the insurance companies smart enough to figure this out and start correcting their rates to be much higher?

That seems like a naive "MARKET WILL FIX IT" approach.

More likely, if the market does fix it, it'll be by having insurance companies deploy actual inspectors who know what they are doing and what sorts of problems to work for.

They might even be a fun combination of physical pentester/irl chaos monkey. Doesn't that sound like a fun job?

Quite often operational losses aren't insured against this kind of error, for example the Knight-Ridder automated trading losses. Sufficiently big operational failures can just destroy companies, especially small companies.

System audits would have to be standardised. There's bits of this in ISO9001, PCI compliance, FIPS, and so on. But the technology changes rapidly and the insurance companies don't have the expertise.

A cynic in me feels that someone will figure out the problems with cascade case and insure from failure of insurance companies to pay out insure money. Just like during 2008 financial crisis.

That's what existing reinsurance companies do, if I understand correctly. They insure the insurance companies.

Cascading failure will be covered in the expected loss, so insurance fees go up and up ?

I think we just need to build smarter. I've become disillusioned with the "runaway state" problem (as well as spaghetti-dependency problems) in OO languages which contributes to bugs and general nondeterministic behavior as well as making long term maintenance difficult, and at the same time I've become enamored of unit test suites and functional immutable languages like Elixir as well as static code analysis tools (I'm still coming around to Haskell-esque typing, but I generally think it's a good idea to write "potentially provably correct" code that has parts which provably have no side effects).

So obviously the "move fast and break things" philosophy is meant for some fun web applications. But what's the equivalent "modern best practice" for systems that are much more weighed towards stability and resilience as opposed to new features?

Systemic quality focus would be a good start. Deming-based management philosophy driving a systems-oriented model.

This actually applies to all businesses; speed improves, market fit improves (quality is just "what is good and valuable" after all), employee happiness improves (exponential gains from that alone). The effects are systemically positive.

But, no one cares, and the belief that we have to crack the whip to get people to make things faster, and we should reward the good people and punish the bad ones—will continue on as pure religious fallacy resulting in the failure or constant-operation-at-the-edge-of-failure of everything involving more than five people, probably until the end of the human race.

Well, on one hand there's six sigma and then there's the agile manifesto.

That's quite a wide gulf.

Would love to hear from people who have worked with developing / managing relatively high quality software with relatively modern methods.

Edit: Maybe NASA's Faster Better Cheaper comes to mind...

Six Sigma and Agile are indeed at pretty opposite sides of the spectrum.

Deming -- W. Edwards Deming, that is -- is somewhere in the middle, around the right balance. He advocated for spreading a philosophy of systems thinking, scientific method, and statistical understanding, while simultaneously empowering employees by recognizing the power and responsibility of management and leadership, and understanding the motivation from a scientifically accurate psychological viewpoint.

It's a correct framework, and it's all aimed at driving quality by improving the things that directly impact it at a base level: fundamentally, how people work together, how they build systems that work, and how they're motivated (and demotivated) in reality.

Schuberg Philis (https://www.schubergphilis.com/) in the Netherlands has been selling 100% functional up-time for a while now. They've set their entire business model and management structure up to support this.

Doesn't come cheap though.

Reply on news.ycombinator.com