I recognize this as a valuable counter point to the "move fast and break things" ethos, but I disagree with the framing. A while ago I learned about a model of

I recognize this as a valuable counter point to the "move fast and break things" ethos, but I disagree with the framing. A while ago I learned about a model of "error budgets" from google[1] which really resonated with me. You want errors to happen sufficiently infrequently that when the user encounters an issue it usually isn't your fault (instead something with the user's hardware, or their ISP, etc). Optimizing beyond this point is a waste of time because you can't eliminate errors that are outside the control of your system. It provides a very well defined framework for how to define the threshold of "does this matter enough to slow down and fix it". [1]: https://sre.google/sre-book/embracing-risk/ https://sre.google/sre-book/embracing-risk/