Fault Tolerance, Borrowed from the Hardware Store
Nicholas C. Zakas recently shared a fitting analogy in his newsletter: painters tape. At first glance, masking tape seems trivial—a bit of low-adhesive paper meant to keep wall paint off the trim. But its real genius is philosophical. Painting is inherently messy. Even a skilled painter will splatter, slip, or lose focus. Rather than trying to avoid every mistake, painters tape makes the inevitable mistakes cheap to fix. You apply it where paint is likely to land, make your mess, and then peel it away to reveal a clean edge. Skip the tape, and that same mistake becomes a costly repair.
Software engineering operates under the same principle. The relevant concept here is fault tolerance. Instead of designing for a best-case scenario where everything runs smoothly, fault tolerance assumes that errors will occur. The goal shifts from preventing every possible failure to ensuring that, when a failure happens, recovery is straightforward.
This is the core question to ask about any piece of code: not if it will fail, but how it will fail. Anticipating the specific ways a system can break allows you to design boundaries around those risk areas—the software equivalent of laying down tape before you start painting. The result is a system where routine mistakes are contained and cleaned up quickly, rather than cascading into larger issues.
