Generalization

Imagine trying to design the ultimate tool — one that can do everything you’ll ever need. Chances are, you’d end up with a clumsy compromise. Like a Swiss Army knife: useful in a pinch, but never the best tool for the job. On the other hand, a tool built for a single task can excel at it, but won’t help when the problem changes.

General systems are versatile. They make few assumptions about their environment, which means they can adapt to a wide range of situations. But that flexibility comes at a cost: general systems often leave performance on the table. They have to prepare for possibilities that may never happen instead of exploiting structure when it’s available.

Specialized systems flip the tradeoff. They take advantage of specific constraints to achieve speed, precision, or efficiency that general systems can’t match. A factory line designed to produce one kind of widget is far more efficient than a workshop that can make anything. A law tailored for a narrow case can be more effective than a broad rule. Within their intended context, specialized systems excel, but step outside that context, and they quickly lose their edge.

That tension runs through every kind of design. We can make a tool that works in many contexts, or one that assumes strong patterns. We can build organizations around flexible roles, or lock in narrow expertise. The more assumptions we bake in, the more efficient we get and the less adaptable we become.

The choice between generality and specialization depends both on context and on use. In stable, predictable environments, specialized systems can deliver unmatched efficiency. The more often they’re exercised, the more those efficiencies compound. But in shifting or uncertain conditions, general systems prove more resilient, even if they give up some performance. The right balance isn’t absolute; it’s shaped by where the system lives and how much it matters in practice.