Proving Its Existence

Software is built on patterns.

This is not an accident.

Programming languages are themselves collections of patterns: syntax, types, functions, objects, and structures that allow us to express complicated ideas through simpler ones.

The software built with those languages naturally follows the same path.

We recognize repetition.

We give it a name.

We place it behind an interface.

We turn it into an abstraction.

This is a beautiful thing.

Abstraction allows software engineers to think beyond individual lines of code. It lets us describe what a system does without carrying every detail of how it does it.

But why should any particular abstraction exist?

Does it exist for its own sake?

No.

Does it exist because someone once said software should be written that way?

No.

An abstraction exists to fulfill a promise.

Perhaps it promises to remove duplication. Perhaps it makes change safer. Perhaps it gives several parts of a system a shared language. Perhaps it protects the rest of the software from a complicated implementation.

Whatever the promise may be, the abstraction proves its right to exist by fulfilling it.

That makes this idea both a principle and a warning.

Imagine that we introduce abstraction B because we expect to eventually need capability C.

The reasoning looks sensible:

A leads to B.

B will someday lead to C.

Therefore, A leads to B, which leads to C.

But what happens if C is never needed?

Now B must justify itself without the future that was supposed to make it valuable.

Sometimes it can.

Often it cannot.

The abstraction remains, but its promise does not. Instead of simplifying the system, it becomes another concept engineers must understand, maintain, and preserve.

This does not mean we should avoid abstraction.

It means abstraction should follow evidence.

Before introducing another layer, interface, or pattern, ask what promise it is making. Ask who needs that promise fulfilled. Ask whether the need exists today or only inside an imagined future.

Then ask the most important question:

Can this abstraction prove its existence?

Because a good abstraction makes complexity easier to carry.

An unnecessary one merely gives it another name.