Law III.

There are two kinds of complexity in every system. Fred Brooks defined this distinction in No Silver Bullet (1986): essential complexity is inherent to the problem; it cannot be reduced without changing what the system does. Accidental complexity is introduced by the solution, the tools, the patterns, the decisions we make along the way. The architect's job is to tell them apart and only fight the one that can be won.

Key Principles

• Essential vs. Accidental.

  A banking system must handle transactions, reconciliation, and regulatory compliance; that complexity is essential. A banking system that requires three YAML files and a custom DSL to deploy a config change, that complexity is accidental.

• Accept What You Cannot Reduce.

  Trying to simplify essential complexity produces systems that are simple but wrong. They ignore edge cases, cut corners on domain rules, or push the complexity onto the user in the form of workarounds.

• Eliminate What You Introduced.

  Accidental complexity is always your responsibility. Every abstraction, every indirection, every "we'll need this later" adds weight. If it doesn't serve the problem directly, it should justify its existence or be removed.

Practical Application

• When a system feels too complex, classify each source of complexity: is it demanded by the problem or introduced by the implementation?
• Resist the urge to abstract essential complexity away. Instead, model it explicitly and make it visible.
• Periodically audit accidental complexity: layers added for flexibility never used, abstractions built for scale never reached, patterns adopted by convention rather than necessity.