3 ms·
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
by kqr 2y ago
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: interactive complexity.
Today's systems are so complicated that many failures stem from insufficient, misunderstood, or ambiguous specifications. These errors happen not because a component failed -- all components work exactly as they were intended to -- it is only that in their intended interactions they produce an unintended result. Failure is an emergent property.
The solution is to approach reliability from a system theoretic perspective. This very early draft contains the core of the idea, but not yet fleshed out or edited: https://entropicthoughts.com/root-cause-analysis-youre-doing-it-wrong https://entropicthoughts.com/root-cause-analysis-youre-doing...
- nostrademons 2y agoThis is why Erlang's OTP focuses on supervisor trees. At each level of the component hierarchy, you have redundancy. Subcomponents themselves may have interactive complexity, but a failure or misspecification in any of the interactions making up that subcomponent simply makes that subcomponent fail. This failure is handled at a higher level by doing something simpler. And "do something simpler" is actually a core part of this strategy. You're right that "today's systems are so complicated that many failures stem from insufficient, misunderstood, or ambiguous specifications". In most cases, yesterday's system worked just fine, you just can't sell it as a competitive advantage. So build simple, well-understood subsystems as fallbacks to the complex bleeding-edge systems, or even just take the software that's been working for a decade.
- detourdog 2y agoI 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.
- gukov 2y agoSystems are not built in one go. They usually start out simple enough and become complex over time.