When does abstraction actually reduce complexity?

[iaversao7-sketch]

In large-scale software systems, how do you decide when adding abstraction actually reduces complexity rather than increasing it? Are there concrete heuristics or signals you rely on beyond “it feels cleaner”?

[DaviBonetto]

I’ve found that abstraction helps only when it removes a concrete source of change, not when it just reorganizes code.

A few signals I usually look for:

Multiple call sites evolving for the same reason. If I see the same modification happening in 3–4 places every time a requirement changes, abstraction tends to pay off.

Stable concepts vs. unstable implementations. I try to abstract around concepts that have stayed semantically stable over time, even if their implementations changed.

Cognitive load, not LOC. If understanding a feature requires holding fewer mental models after the abstraction than before, it’s probably a win.

On the flip side, abstraction becomes harmful when:

It introduces indirection without insulation you still need to understand the underlying details to make changes.

The abstraction is speculative, built for “future use cases” that never materialize.

Debugging forces you to mentally traverse multiple layers just to answer a simple question.

Over time, I’ve stopped asking “is this cleaner?” and started asking “will this abstraction age better than the code it replaces?”. If the answer isn’t clearly yes, I usually keep things concrete a bit longer.