The Paradox of Reuse: Premature Abstraction

In every engineering organization, there is a person who wants to "genericize" everything. They see two things that look the same, and they want to create a third thing that can do both.

This is the DRY (Don't Repeat Yourself) principle taken to its logical, but destructive, extreme.

The Cost of Flexibility

Abstraction is not free. Every layer of abstraction you add to a system is a layer of cognitive load for the next developer.

When you abstract too early—before you've seen a pattern repeat three or four times—you are making a guess about the future. And if you guess wrong, you've now "locked" the system into a rigid structure that doesn't quite fit either use case perfectly.

Sanding the Corners

When we try to make one component handle two different slightly-varying needs, we start adding "flags" or "options."

• if (mode == 'simple') { ... }
• if (user.isAdmin()) { ... }

Soon, the generic component is a mess of conditional logic. It becomes harder to test and harder to reason about. It would have been better to have two simple, duplicate components that shared no code but were easy to delete when one of them was no longer needed.

The Rule of Three

A good rule of thumb: Duplicate your code once. Duplicate it twice. If you're about to duplicate it a third time, only then should you consider an abstraction.

By the third time, you've seen enough "variation" to know what the truly generic parts are. You are no longer guessing.

The Goal is Simplicity

We should always favor a simple, concrete solution over a complex, abstract one. If you can't explain why a generic solution is better than a simple one, don't build it.

The goal of architecture is to make things easier to change. Premature abstraction does the opposite: it makes things harder to change because the impact of the change is now hidden behind layers of indirection.