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

11–20 of 58 posts

Re: Practices of Reliable Software Design

#11

Post by u8_friedrich »

> It is much easier to add features to reliable software, than it is to add reliability to featureful software.

Not sure about this tbh. In a lot of cases yeah maybe. But when you are dealing with complicated business logic where there is a lot of bells and whistles required, building a simple reliable version can lead you into a naive implementation that might be reliable but very hard to extend, while making an unstable complicated thing can help you understand the pit falls and you can work back from there into something more reliable. So I think this depends very much on the context.

Re: Practices of Reliable Software Design

#12

Post by bruce511 »

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 maintain written-by-me code is added in.

Things that are bought -tend- to last longer too. If I leave my job I leave behind a bunch of custom code nobody wants to work on. If I leave Redis behind, well, the next guy just carries on running Redis.

I know all this. I advocate for all this. But I'm a programmer, send coders gotta code:) do it's not like we buy everything, I'm still there, still writing.

Hopefully though my emphasis is on adding value. Build things that others will take over one-day. Keep designs clean, and code cleaner.

And if I add one 'practice' to the list; Don't Be Clever. Clever code is hard to read, hard to understand, hard to maintain. Keep all code as simple as it can be. Reliable software is software that mostly isn't trying to be too clever.

Re: Practices of Reliable Software Design

#13

Post by aitchnyu »

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…

This topic deserves an article on its own. I feel my team crossed "the line" on a SaaS that hosts docs from our Openapi and page doesnt even refresh safely. But how do we define the line?

Re: Practices of Reliable Software Design

#14

Post by kqr »

aitchnyu wrote: post #13
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…

This topic deserves an article on its own. I feel my team crossed "the line" on a SaaS that hosts docs from our Openapi and page doesnt even refresh safely. But how do we define the line?

The line is where the cost of building is less than that of buying. It sounds like in your case building would have been cheaper, given the simplicity of the problem and the quality issues with the purchased solution.

It does get difficult in more complicated cases thanks to a lack of information on what a good solution looks like. This article attempts to straighten it out a little: https://entropicthoughts.com/build-vs-buy

Re: Practices of Reliable Software Design

#15

Post by SomewhatLikely »

My first thought upon seeing the prompt:

    If you would build an in-memory cache, how would you do it?

    It should have good performance and be able to hold many entries. 
    Reads are more common than writes. I know how I would do it already, 
    but I’m curious about your approach.
Was to add this requirement since it comes up so often:

    Let's assume that keys accessed follow a power law, so some keys get 
    accessed very frequently and we would like them to have the fastest 
    retrieval of all.
I'm not sure if there are any efficient tweaks to hash tables or b-trees that might help with this additional requirement. Obviously we could make a hash table take way more space than needed to reduce collisions, but with a decent load factor is the answer to just swap frequently accessed keys to the beginning of their probe chain? How do we know it's frequently accessed? Count-Min sketch?

Even with that tweak, the hottest keys will still be scattered around memory. Wouldn't it be best if their entries could fit into fewer pages? So, maybe a much smaller "hot" table containing say the 1,000 most accessed keys. We still want a high load factor to maximize the use of cache pages so perhaps perfect hashing?

Re: Practices of Reliable Software Design

#19

Post by pistoleer »

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?

Re: Practices of Reliable Software Design

#20

Post by lucianbr »

manvillej wrote: post #8
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 simple basic reality of statistics, a binomial distribution. 5 independent systems with 90% chance of success is mathematically as reliable as one that is 99.999%. 100x 90% systems would get you to 100 "9s" of reliability aka 99.99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999%

Actually making 5 completely independent systems would be exceptionally hard. No shared code or team members, no shared hardware... For example, what 5 computing platforms would you use? x86, ARM, RISC-V and...?

Math rarely applies so easily to real life. Talking about "independent" systems is cheap.

If at all possible. How would you transport yourself to work using two independent systems?

Post reply on HN