Law II.

Every application carries a baseline of intrinsic complexity that cannot be eliminated, only moved. The architectural decision is not whether complexity exists, but who will bear it: the developer, the platform engineer, or the end user.

Key Principles

• Irreducible Complexity.

  There is a minimum amount of complexity inherent in every problem. No abstraction, framework, or tool can make it disappear; it can only shift it from one layer to another.

• Deliberate Allocation.

  Decide explicitly where complexity should live. Hiding it from the developer often pushes it to the platform. Hiding it from the platform often pushes it to the user. The worst outcome is when no one decides and complexity leaks everywhere.

• Protect the End User.

  When in doubt, absorb complexity on the engineering side. A system that is hard to build but simple to use is always preferable to one that is easy to build but painful to operate.

Practical Application

• Before simplifying one layer, ask where the complexity will resurface.
• Map your system's complexity: identify what is handled by the developer, the platform, and the user. Look for imbalances.
• When evaluating an abstraction, verify it is not just deferring complexity to the next person in the chain.