Great points. But why do we invest so much complexity into outputting html/js/css.
Practices of Reliable Software Design
31–40 of 58 posts
Re: Practices of Reliable Software Design
#32I 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.
Re: Practices of Reliable Software Design
#33Earlier quoted context omitted.
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?
It's relatively simple at the organizational level, just expensive (but linearly expensive, while often increasing subcomponent reliability is exponentially expensive!). Just give the same problem statement to two independent teams with two different managers, have a clear output format and success criteria, and let them make all their technical decisions independently. Your example of "how do you transport yourself…
While these are reasonable approaches, I do not think they live up to the mathematical meaning of "independent", and so invalidate the chances calculation.
Your two teams might well both use in some place in the system the same hardware or software component. This will make the probability of failure between the systems not be completely independent, for all that you paid two teams and they worked separately. Spent a lot of money, and the results will not be as expected. If they both use x86 Intel, and a Meltdown kind of thing happens, your "independent" systems will both fail from the same cause.
The transport analogy works great if you somehow imagine the transportation to be instantaneous, and only the decision to matter. But if you are already on a train and the train is delayed, you are not walking back home and taking the car. You have multiple options for transport, but you do not have a system built of independent components. You are not using the train and the car and the highway and the local roads all simultaneously.
I don't think you understand the requirements for the formula you wrote to be valid. Your examples do not fit, for all that they are reasonable and useful approaches. Your actual reliability with these approaches falls way below the multiple nines you think of.
Re: Practices of Reliable Software Design
#34[dead]
Re: Practices of Reliable Software Design
#35There 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…
> For any given task, compute the answer multiple times in parallel, ideally in multiple independent ways.
Just to be clear, while this particular technique is valid and used in space software, it isn't common at all in Erlang and not part of the "let it crash" principle.
Re: Practices of Reliable Software Design
#36There 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…
As always, life is not that simple, and redundant components can interact in harmful ways, correctness checks can create incorrectness, process managers or consensus algorithms can amplify small problems...
Just like every technique on the article also can turn out to reduce your reliability too.
Re: Practices of Reliable Software Design
#37There 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…
In the limit, there is a hard tradeoff between efficiency and reliability. Failovers, redundancies, and backups are all important for building systems that are resilient in the face of problems, for reasons you've pointed out. However, failovers, redundancies and backups are inefficient. Solving a problem with 1 thing is always going to be more efficient that solving the same problem with 10 things. It's interesting…
> In the limit, there is a hard tradeoff between efficiency and reliability.
Yes, but notice that most things on the GP's comment have an exponential impact on reliability (well, on 1 - reliability), so they are often non-brainiers as long as they follow that simple model (what they stop doing at some point).
Re: Practices of Reliable Software Design
#38Earlier quoted context omitted.
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/buil…
> The line is where the cost of building is less than that of buying.
Yes, once you factor in transaction costs, integration costs, risks contamination from that 3rd party, risks from lack of value alignment with that 3rd party (remember the Unity game engine?)...
Or, in other words, people that say that phrase you said very often don't know the actual cost of buying. But well, nobody knows the actual cost of building before they try either.
Re: Practices of Reliable Software Design
#39Great points. But why do we invest so much complexity into outputting html/js/css.
Because html/js/css is the venue for a massive fraction of human-computer interactions, and there a lot of different things we want to accomplish between humans and computers.
It’s always funny to me when people act like “websites” are some trivial, silly little area of software, when in fact for a lot of people, it’s their primary use of a computer.
Re: Practices of Reliable Software Design
#40Earlier quoted context omitted.
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/buil…
I would personally replace 'cost of building' with 'cost of maintaining', but otherwise agree with your reasoning. It's worth building in a factor of safety, such that I would formulate this idea as:
Only build software if the cost of maintaining it is 1/3 or less than the cost of buying a license.
(this has the nice second-order effect of being more robust to errors in the maintenance estimate, hence making it quicker to estimate).