Fail Fast and Building Large Systems

"Fail fast" is useful when it means finding false assumptions while the cost of change is still low.

It becomes harmful when it is treated as a complete strategy for large systems. A running product, a production database, a migration path, a reliability program, or a hardware program cannot be improved by failing casually.

Large systems need experiments, but they also need design judgment, redundancy where it buys safety, optimization where it removes a real constraint, and people with enough attention to close the loop.

The disagreement in this note is with the shortcut version of the phrase. Complexity does not become manageable because an organization accepts failure as a slogan. It becomes manageable when failures are captured, studied, and turned into structure: tests, safer rollouts, clearer boundaries, better instrumentation, and a design that can keep moving.

For software, the practical rule is simple: run small experiments at the edge of uncertainty, but do not confuse avoidable damage with learning.