Complexity Should Be Hidden

Complexity is inevitable, but it should be concealed behind simple interfaces and pushed down and inward, so that most people most of the time never have to confront it. The quality of a design is measured by how little complexity it exposes, not by how clever its internals are.

Reinforced By

• Complexity — the force that hiding exists to contain.
• Deep Modules and Information Hiding — a lot of capability behind a small, stable interface.
• Pull Complexity Downward — when complexity is unavoidable, the implementer absorbs it so callers do not.
• Cognitive Load — the org-level budget that hiding complexity protects.

Why it Matters

The same worldview shows up at two scales. A Philosophy of Software Design applies it to code: deep modules, information hiding, and pulling complexity downward all keep complexity out of sight. Team Topologies applies it to organizations: platforms exist to absorb complexity so stream-aligned teams stay within their cognitive load. In both, the goal is not to eliminate complexity but to relocate it to where it is best managed.

Tension

Hidden is not gone. Pushed-down complexity still exists and can leak through abstractions, and concealing behavior can also conceal something a user genuinely needed to see. The discipline is to hide what callers should not care about while keeping essential behavior legible.