3 ms·
Where does it stop though? Because in that case all externalities will become a "I trusted that dependency but it failed, why did I trust it and didn't work aro
by rakoo 8y ago
Where does it stop though? Because in that case all externalities will become a "I trusted that dependency but it failed, why did I trust it and didn't work around it?".
- kevingadd 8y agothe causes of failures that you explicitly enumerate which were under your control aren't always You Did A Bad Thing. For example, "I trusted this dependency which broke" doesn't mean you Did Something Bad, it just means that the cause of the failure was the lack of a way to validate the dependency and fall back on a known-good version. A good example of this is build pipelines relying on the ability to download npm/nuget/debian packages from a remote server instead of vendoring them locally - this is an intrinsically unreliable choice to make. The remote server being unreachable is not your fault, but there are steps you can take to fix this problem in the future. Avoiding external blame in your 5Ys (without ignoring the external factors) encourages you to make local changes. As always you have to apply reason here and not adhere to dogma, but it's a useful dogma.
- dtech 8y agoIt's okay to conclude after a root cause analysis that the root cause is not something you want to work to prevent, because the cost-benefit is skewed. For some products a AWS S3 [1] outage might be a influential enough that they add a redundant second storage at another provider, for other it might be "this is too expensive and time consuming to work around for the problems it caused, let's hope Amazon gets their shit together" [1] https://aws.amazon.com/message/41926/ https://aws.amazon.com/message/41926/