Needless complexity: the price of “just in case”

Needless complexity is almost never born from bad intent. It is born from good intent: “in case we need multiple databases”, “in case we plug in another provider”, “in case the team grows”. Every “just in case” adds a layer. And every layer is paid for — not the day you write it, but every day after.

The cost is daily, the benefit is hypothetical

A “just in case” abstraction is read at every debug session, worked around at every change, explained at every onboarding. The scenario it prepares for often never happens — or happens in a shape the abstraction did not anticipate, and you have to undo it anyway.

Three questions to sort it out

Facing an existing layer, or one you are about to write: does a real case use it today? If you removed it, what would concretely break? Will the person reading this code in a year understand why it exists without being told? Three “no”s = a layer to remove.

Sobriety is not naivety

This is not about writing simplistic code that ignores real needs. It is about waiting for the need to exist before paying for it. A sober system can host complexity — when justified by a real case, it integrates cleanly. It is speculative complexity that rots: it structures the code around imaginary scenarios.