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

Practices of Reliable Software Design

entropicthoughts.com

Post reply on HN
Print view View original

41–50 of 58 posts

Re: Practices of Reliable Software Design

#41

Post by the_sleaze_ »

pistoleer wrote: post #19
nostrademons wrote: post #2

There is a bunch of good advice here, but it's missed the most useful principal in my experience, probably because the motivating example is too small in scope: The way to build reliable software systems is to have multiple independent paths to success. This is the Erlang "let it crash" strategy restated, but I've also found it embodied in things like the architecture of Google Search, Tandem Computer, Ethereum, RAID…

Who will replicate the consensus checker?

Because he's the failover Gotham deserves, but not the validator it needs right now

Re: Practices of Reliable Software Design

#42

Post by detourdog »

kqr wrote: post #10
nostrademons wrote: post #2

There is a bunch of good advice here, but it's missed the most useful principal in my experience, probably because the motivating example is too small in scope: The way to build reliable software systems is to have multiple independent paths to success. This is the Erlang "let it crash" strategy restated, but I've also found it embodied in things like the architecture of Google Search, Tandem Computer, Ethereum, RAID…

I disagree somewhat, influenced by the teachings of Nancy Leveson. In the 1930's, yes, component redundancy was the way to reliability. This worked at the time because components were flaky and technical systems were simple aggregations of components. Today, components themselves are more reliable, but even when they are not, redundancy adds only a little reliability because there's a new, large, source of failure: i…

I have the opinion that todays very complicated system is a symptom of over complication for the problem at hand.

I’m working on the idea that there is better set of assumptions to use for directing technical development.

Re: Practices of Reliable Software Design

#43

Post by taeric »

This misses one of the key things I have seen that really drives reliable software. Actually rely on the software.

It sucks, because nobody likes the idea of the "squeaky wheel getting the grease." At the same time, nobody is surprised that the yard equipment that they haven't used in a year or so is going to need effort to get back to working. The longer it has been since it was relied on to work, the more likely that it won't work.

To that end, I'm not arguing that all things should be the critical path. But the more code you have that isn't regularly exercised, the more likely it will be broken if anything around it changes.

Re: Practices of Reliable Software Design

#44

Post by amelius »

nostrademons wrote: post #2

There is a bunch of good advice here, but it's missed the most useful principal in my experience, probably because the motivating example is too small in scope: The way to build reliable software systems is to have multiple independent paths to success. This is the Erlang "let it crash" strategy restated, but I've also found it embodied in things like the architecture of Google Search, Tandem Computer, Ethereum, RAID…

> The way to build reliable software systems is to have multiple independent paths to success.

That's a heuristic that might work sometimes.

If you really want to build reliable software systems, then at least prove them correct. There are some tools and methodologies that can help you with this. And of course even a proof isn't everything since your assumptions can still be wrong (but in more subtle ways).

Re: Practices of Reliable Software Design

#45

Post by eikenberry »

bruce511 wrote: post #12

The first point is one that resonates strongly with me. Counter-intuitivly, the first instinct of a programmer should be "buy that, don't write it" Of course, as a programmer, this is by far not my first instinct. I am a programmer, my function is programming, not purchasing. Of course buying something is always cheaper (compared to the cost of my time) and will be orders of magnitude cheaper once the costs to mainta…

> Counter-intuitivly, the first instinct of a programmer should be "buy that, don't write it"

I don't think this is counter intuitive at all... this is the whole premise behind free software. Why write it yourself when someone else already has and there is a community around using and updating it. We all buy the vast majority of our software and it is usually our go to move, unless there is an itch.

Re: Practices of Reliable Software Design

#47

Post by VyseofArcadia »

bruce511 wrote: post #12

The first point is one that resonates strongly with me. Counter-intuitivly, the first instinct of a programmer should be "buy that, don't write it" Of course, as a programmer, this is by far not my first instinct. I am a programmer, my function is programming, not purchasing. Of course buying something is always cheaper (compared to the cost of my time) and will be orders of magnitude cheaper once the costs to mainta…

I'm not sure I 100% agree.

I've been thinking a lot lately about the cost of off-the-shelf solutions from the perspective of sustainability, and there is a cost beyond money. The performance of software almost always degrades over time. By buying Foo off-the-shelf, you are saying, "I am ok with getting on the same bloat-dictated hardware upgrade cycle as Foo."

Of course you have the option of buying Foo and never upgrading, unless Foo has a license that forces you to. But that also walls you off from security bugfixes. But by replicating the essential features of Foo in-house, you can actually set and stick to a complexity and performance budget.

Of course if you are a business of any real size, you're already on the hardware upgrade treadmill anyway, and probably all of your customers are too, so what does it matter if your software is a little slower and a little more resource hungry year after year after year? Other than maybe a little twinge of guilt every now and then.

Re: Practices of Reliable Software Design

#48

Post by gukov »

detourdog wrote: post #42
kqr wrote: post #10

Earlier quoted context omitted.

I disagree somewhat, influenced by the teachings of Nancy Leveson. In the 1930's, yes, component redundancy was the way to reliability. This worked at the time because components were flaky and technical systems were simple aggregations of components. Today, components themselves are more reliable, but even when they are not, redundancy adds only a little reliability because there's a new, large, source of failure: i…

I have the opinion that todays very complicated system is a symptom of over complication for the problem at hand. I’m working on the idea that there is better set of assumptions to use for directing technical development.

Systems are not built in one go. They usually start out simple enough and become complex over time.

Re: Practices of Reliable Software Design

#49

Post by LorenPechtel »

taeric wrote: post #43

This misses one of the key things I have seen that really drives reliable software. Actually rely on the software. It sucks, because nobody likes the idea of the "squeaky wheel getting the grease." At the same time, nobody is surprised that the yard equipment that they haven't used in a year or so is going to need effort to get back to working. The longer it has been since it was relied on to work, the more likely th…

Yup. Dogfood everything you can. Too often I've seen things that could never have made it out the door if whoever designed them actually used them or worked with those who used them.

Re: Practices of Reliable Software Design

#50

Post by LorenPechtel »

AnimalMuppet wrote: post #32
l5870uoo9y wrote: post #16

I would add a ninth practice; throw errors. You find and fix them as opposed to errors that go silently unnoticed in the code base.

Fail early, and fail noisily . Don't fail silently.

Yes, .NET. I really love how an uncaught exception in a secondary thread simply causes a silent termination of the thread. In the development environment (C#) things work normally but a release version silently eats them.
Post reply on HN