YAGNI

The Problem It Solves

A team builds a plugin system for a report exporter. Three years later: zero plugins exist, but every reader pays the interface tax, the factory tax, and the registry tax — permanently. The capability nobody needed consumed real delivery time (illustrative: if it took 30% of the sprint, the team shipped its actual features 30% slower) and charges maintenance interest forever.

YAGNI (from XP, Kent Beck) is the discipline of implementing what is required now, deferring what is merely imagined — because imagined requirements usually never arrive, and when they do, they arrive different from the prediction.

Why Predicting Is Losing

 Speculated today                        Reality later
 ┌──────────────────────┐                ┌──────────────────────┐
 │ interface Exporter   │                │ "we need S3 upload   │
 │ + factory            │    usually     │  AND PDF watermark"  │
 │ + plugin registry    │ ────────────►  │ → guessed seam fits? │
 │ (built for plugins   │     never      │   usually NO:        │
 │  that never come)    │     matches    │   rework anyway      │
 └──────────────────────┘                └──────────────────────┘

The speculation fails twice: cost paid upfront, and rework when reality differs — the abstraction built on wrong guesses is often harder to remove than no abstraction at all.

Detection Signals

• Interface with exactly one implementation, no test stub, no stated variant plan.
• Configuration knobs nothing has ever turned.
• Abstract base class with one concrete child and no extension point in docs.
• Parameters added “for future use” silently ignored by implementations.
• Layers whose only job is forwarding calls.

What YAGNI Is Not

Misreading	Correction
”Write sloppy code”	Simple ≠ careless — invariants still enforced
”Never design ahead”	Design seams are cheap; full machinery isn’t. Interface where change is stated = fine
”Ignore performance”	Hoare’s misquoted line targets micro-optimization without measurement, not sound structure
”Skip validation”	Trust-boundary checks are current requirements, always

Decision Rule

Build the general mechanism only when at least one holds:

1. Two or more real variants exist today.
2. A requirement document explicitly promises the variant.
3. The seam doubles as a test boundary you need now.

Otherwise write the direct version — extraction later costs hours; deleting a wrong abstraction costs days plus review trust.

Interview Signals

• Candidates who add interfaces for every entity “in case” score lower than those who justify each seam.
• The scoring sentence: “single implementation today; I’d extract an interface the moment a second storage engine appears.”