What concrete costs does strictly enforcing inward-pointing dependencies (ports/interfaces for every outward call) impose on a codebase, and under what circumstances would you deliberately not enforce it?

## The fixed cost of a seam Every port-and-adapter seam has a **fixed cost that gets paid regardless** of whether the seam is ever used for its intended purpose. Concretely: for each outward dependency a team decides to invert, someone - writes an interface - writes (or already has) a concrete implementation of it - writes the code that wires the two together at a composition root - often writes a translation/mapping layer between the inner model's shape and the outer system's shape A reader trying to understand what actually happens when an order is saved now has to follow a call from a use case, through an interface, to a class located in a different package, possibly resolved by a DI container at runtime rather than visible from a simple 'go to definition.' None of this is expensive in isolation, but multiplied across every repository, every external API call, every file write in a codebase, it adds up to meaningfully more files, more indirection, and slower onboarding for new engineers who have to learn where 'the real implementation' lives for each interface. ## The tension with YAGNI This cost is worth naming honestly because it's in real tension with a competing, equally legitimate principle: **YAGNI** ('you aren't gonna need it') and the well-known observation that **duplication is far cheaper to live with than the wrong abstraction**. An interface introduced 'in case we need to swap databases someday' that never gets a second implementation is a pure cost with no realized benefit — it's **speculative generality**, and it's arguably a bigger design smell than the coupling it was meant to prevent, because at least a direct dependency is honest about what the code actually does. A **'just-in-time'** approach to this kind of abstraction is common in practice: start with the direct, simple dependency, and only invert it once you have a second concrete reason to (a second real implementation, or a genuine need to unit-test without infrastructure) rather than pre-emptively. ## When I would relax it Concretely, I'd relax strict inward-pointing discipline in a handful of recurring situations. - **Early-stage prototypes and MVPs**, where the team's actual risk is 'nobody wants this product,' not 'we might swap Postgres for DynamoDB' — the fastest path to learning that trumps architectural purity, and the code is often thrown away or heavily rewritten regardless. - **Small internal tools and one-off scripts** with a single, known-forever technology choice and a tiny number of maintainers who can hold the whole thing in their head — the indirection buys nothing because there's no meaningful complexity to hide it from. - **Simple CRUD services** with no plausible multi-database or multi-provider future, where the persistence technology is treated as effectively part of the platform — here, testing against a real, fast, disposable test database can be a perfectly good substitute for the isolation an interface would buy, without paying the interface's tax on every change. - **And I'd always exempt glue/composition-root code** — bootstrap functions, DI configuration classes, mapping/adapter code whose entire purpose is bridging inner and outer worlds — from the rule, since forcing that code to also point inward is incoherent; its job is to know about both sides. ## The two failure modes The failure mode on the over-enforcement side is **'interface-itis'**: a codebase where nearly every class has a matching interface/implementation pair with exactly one implementation that will, realistically, ever exist, where every change touches twice as many files as it actually requires, and where new team members spend their first weeks just learning to navigate indirection rather than reading straightforward code. It's the mirror image of the under-enforcement failure mode (business logic wired directly to a database class, unable to be tested or swapped) — both are real, and a senior engineer's job is judging, case by case, which risk is more expensive for the specific piece of code in front of them, rather than applying either extreme uniformly across a whole codebase. ## A reasonable default A reasonable default in practice: apply strict inward direction at genuine architectural seams — the persistence layer, external payment/notification providers, anything with more than one real or planned implementation, or anything you need to test without infrastructure — and allow direct, simple dependencies for stable, single-implementation, low-risk technical choices. **The judgment call itself, not a blanket rule in either direction, is the actual skill being exercised here.**