The Quiet Cost of Abstraction

Abstraction is usually sold as kindness. We will hide the ugly part so that everyone else can think about the real problem. Sometimes that is true. Often we have only moved the ugly part into a room with worse lighting.

The cost is not just indirection, though indirection is real. The cost is the story you now have to keep true. A `PaymentService` promises that payments are one idea. The day refunds, chargebacks, and offline invoices arrive, the name starts lying. People trust the name longer than they trust the code.

A tax I apply in review

1. Can I delete this layer and still explain the system in five minutes?
2. Does the name still match the side effects?
3. Is there one file a new hire should open, or twelve?
4. Are we abstracting variation we have, or variation we fear?

Fear-driven abstraction is the expensive kind. We imagine a second database, a second vendor, a second region, and we build a seam for a future that never pays rent. Meanwhile the present pays in stack traces that bounce between folders like a rumor.

If the only user of an interface is a single implementation, you do not have an interface. You have a rumor of a future.

I like systems that look a little naive and tell the truth. A function called `chargeStripe` can grow up. A function called `fulfill` can only disappoint.