"Any problem can be solved by adding a level of indirection — except too many levels of indirection." How do you decide when an indirection is worth adding, and what does an unjustified one cost?

## The aphorism The first half — *"All problems in computer science can be solved by another level of indirection"* — is attributed to David Wheeler and popularized by Butler Lampson. The second half — *"…except the problem of too many levels of indirection"* (Kevlin Henney's addition) — is the part senior engineers are actually tested on. Indirection is the GRASP principle of putting an intermediate object between two components so they stay decoupled; it is genuinely powerful and genuinely not free. ## The ledger ### Benefits (each must be *claimed specifically*) 1. **Substitutability** — a second implementation exists (vendor B, in-memory store, feature-flagged rollout). 2. **Change containment** — the far side is outside your control and changes on its own schedule (third-party API, another team's service, a wire format). 3. **Test seam** — the caller cannot be unit-tested without cutting here (network, clock, filesystem, randomness, payments). 4. **Cross-cutting hook** — one place to add retries, timeouts, circuit breakers, caching, authorization, tracing, transactions. 5. **Cycle breaking** — A and B need each other; both depending on M turns a cycle into a DAG. 6. **Mesh collapsing** — N peers × N references becomes N × 1 via a hub. 7. **Vocabulary protection** — foreign concepts (HTTP codes, ORM entities, protobuf types) stop at the boundary instead of leaking through the domain. 8. **Organizational boundary** — two teams need a stable contract to release independently (Conway's law made explicit). ### Costs (paid whether or not the benefit materializes) 1. **Traceability.** Every hop is another file to open when reading a bug. "Go to definition" lands on an interface; you need "go to implementation", and with dependency injection the wiring may be invisible in source. 2. **Cognitive load.** Understanding a feature now requires holding several vocabularies at once. 3. **Mapping tax.** Layers usually bring DTOs and mappers; a field addition becomes an edit in four files. 4. **Test surface.** Each layer wants its own tests; over-mocked tests then verify the *wiring* rather than the *behaviour*, and pass while the system is broken. 5. **Runtime cost.** If the indirection is a network hop, a queue, or a serialization boundary, you buy latency, partial failure, ordering questions, and new operational alarms. 6. **Abstraction lock-in.** Once callers depend on your interface, changing it is a coordinated migration. Sandi Metz: *"duplication is far cheaper than the wrong abstraction."* 7. **False safety.** A leaky mediator (vendor types in the signatures, `Any`/`Map<String,Object>` escape hatches, provider-specific error codes) gives you the cost with none of the containment. ## Decision heuristics **The one-sentence test.** "This exists so that X can change without touching Y." If you can't fill in X and Y with concrete names, don't add it. **Rule of three.** Extract the abstraction when the third concrete case shows up. With one case you are guessing at the axis of variation; with two you may be pattern-matching on coincidence. **Reversibility (one-way vs two-way doors).** Adding an indirection later, when the second implementation actually arrives, is a mechanical refactor. Removing one that fifty call sites and a public contract depend on is a project. Prefer the cheap-to-reverse direction: start concrete. **YAGNI vs the exception.** "You aren't gonna need it" is the default; the honest exceptions are (a) crossing a boundary you don't own, and (b) boundaries that are expensive to introduce later — public APIs, persistence formats, cross-team contracts, anything with data migration attached. **Does the layer add or forward?** If every method forwards 1:1 with the same types and no policy, the layer is a pass-through. Delete it or give it a job. **Who owns the contract?** A good indirection's interface is written in *your* vocabulary. If it reads like the vendor's SDK, you built a rename, not a boundary. **Count the hops per request.** A useful architecture review metric: for one representative use case, how many objects does control pass through, and what does each contribute? Hops that contribute nothing are the budget you can reclaim. ## Worked examples **Justified.** A payments integration behind `PaymentGateway`: the vendor is external (change containment), tests must not hit the network (test seam), retries/idempotency live in one place (cross-cutting), and a second provider is a plausible commercial requirement (substitutability). Four benefits, one hop. **Unjustified.** `IUserService` with a single implementation `UserService`, methods identical, existing "so we can mock it". Modern test tooling can fake concrete classes; the second implementation never came. Cost: two files, an indirection in every trace, zero decoupling. **Actively harmful.** A repository interface whose methods take the ORM's criteria objects and return ORM entities. Callers still depend on the ORM, the interface cannot be implemented by anything else, and swapping technologies still touches everything — while the team believes it is protected. **Cost paid deliberately.** An anti-corruption layer between a modern domain and a legacy mainframe: verbose, duplicative, and correct — because the alternative is legacy concepts colonizing the new model. ## What good looks like in an interview answer Don't argue "layers good" or "layers bad". Show that you price the hop: name the specific benefit claimed, name the specific cost paid, note that the decision is easier to reverse in one direction than the other, and give a case where you would deliberately accept a costly indirection anyway.