In 1999, we realized a simple mistake could break the world. For decades, programmers saved space by storing years as two digits—79 for 1979. No one thought their code would still be running when the year 2000 arrived. Then it did, and suddenly, “00” might mean 1900. Banks, airlines, and governments scrambled to fix it. The code wasn’t broken; it just followed bad assumptions.

When you write software, you imagine a tidy world where inputs match expectations. In reality, the world is messy. Take a restaurant’s point-of-sale system. On paper, it’s simple: a customer orders, pays, and leaves. But in practice, one wants to split the bill three ways, another pays half in cash and half with gift cards, and someone else insists on using a coupon from 2016. Suddenly, you’re not just processing payments—you’re managing chaos.

And it’s not just restaurants. Airline booking systems work fine until a storm cancels flights, forcing a cascade of rebookings under obscure policies. Trading platforms hum along—until a market crash turns them into a bottleneck of panicked sell orders. What we call “edge cases” aren’t rare anomalies; they’re the default state of reality.

At first, the solution seems obvious: anticipate every possible scenario. But adding more rules and checks only makes systems more complex—and complexity breeds its own failures. Instead of trying to force reality into a neat mold, you must build systems that are resilient to the unexpected. Assume things will go wrong. Design for failure—not by eliminating errors, but by containing them.

The key insight is simple: the world is an edge case. The sooner you accept that, the better your software will be at surviving it.