First Principles: Fewer Abstractions, Not More

Every client codebase I've audited this year has the same disease: too many abstractions. Base classes inherited by one subclass. Interfaces with one implementation. Factory methods for objects that are only ever constructed one way. The pattern is always the same, and the fix is always the same: delete the abstraction.

Why Abstractions Multiply

Abstractions feel like senior engineering. Somebody thought ahead, considered the future, designed for extension. The problem is that future almost never arrives in the shape you expected. The abstraction exists to serve a use case that never materialized.

Meanwhile, every new developer on the team has to read through three layers of inheritance to understand what actually happens when a request comes in.

The Rule of Two

I don't introduce an abstraction until I have two concrete implementations that need it. Not one plus a hypothetical. Two, today, in the codebase, with real behavior. Before then, the abstraction is guessing, and my guesses are usually wrong.

# Premature: one sender, wrapped in an interface
class EmailSender(Protocol):
    def send(self, to, subject, body): ...
class SESEmailSender: ...
 
# Honest: one sender, no interface yet
def send_email(to, subject, body):
    ses.send_email(...)

When a second provider shows up, I extract the interface. Until then, I use the concrete function.

The Compounding Cost

Every unnecessary abstraction is tax on every future read. For a codebase that lives five years, the tax adds up to weeks. For a codebase that dies in six months, the tax was pure waste. Write for the codebase you actually have.