YAGNI: You Aren't Gonna Need It

YAGNI stands for “You Aren’t Gonna Need It” — one of the simplest, most violated rules in software engineering, and one of the most valuable. It comes straight out of Extreme Programming (XP): don’t write code today for a requirement you only suspect will show up tomorrow.

Every engineer has felt the temptation. “We’ll probably need multi-region failover later, so let me architect for it now.” “Let me make this config-driven with a plugin system, just in case.” YAGNI is the discipline that tells you to stop — and it pays off in fewer bugs, smaller surface area, and faster delivery.

What YAGNI actually means

The rule is precise, not dogmatic. YAGNI says: do not implement a feature until there is a concrete, current requirement for it. The key word is concrete. A vague hunch about the future is not a requirement; a user story, a ticket, or a real downstream dependency is.

It does not say “don’t design clean code” or “ignore the next person who touches this.” Good abstractions still matter. YAGNI targets speculative functionality — code paths, flags, and infrastructure that exist only because someone imagined a scenario.

The XP formulation, from Beck’s Extreme Programming Explained, is blunt:

“Always implement things when you actually need them, never when you just foresee that you need them.”

Why we keep breaking it

The trap is that speculative code feels responsible. Adding a generic abstraction looks like foresight; in reality it is a loan taken against a future that may never arrive.

The real costs show up fast:

• More surface area, more bugs. Every line you ship is a line that can fail. Code written for a hypothetical requirement is also code written without a real test case behind it — the worst kind.
• Slower delivery. Time spent building the “maybe later” feature is time not spent shipping the feature the user is actually waiting for.
• Premature generalization rots. The abstraction you designed for three imaginary callers usually doesn’t match the one real caller that eventually shows up. You throw it away anyway — after maintaining it for a year.
• Cognitive load. Future readers (including you, in three months) have to understand machinery that does nothing today.

I have watched platform teams spend weeks standing up a multi-tenant control plane “because we might sell it as SaaS,” while the single-tenant deployment they actually run limped along unbuilt. The speculative work wasn’t free — it was a tax on the real one.

YAGNI vs the other principles (they aren’t in conflict)

A common objection: “Doesn’t DRY say reuse everything, and doesn’t SOLID say build for extension?” They coexist, but at different levels:

• DRY (Don’t Repeat Yourself) is about knowledge, not speculation. Duplicating real, current logic is a bug; inventing a shared module for logic you don’t have yet is YAGNI’s enemy.
• SOLID is about keeping existing code changeable. Good interfaces help you add the real feature later — they don’t require you to add it now.
• KISS (Keep It Simple, Stupid) is the closest cousin. KISS says build the simplest thing that works; YAGNI says don’t build the thing at all until it’s needed.

The practical rule I use: design for change, don’t build for change. A clean seam where a feature could attach is cheap. The feature itself, wired up and tested and maintained, is not.

YAGNI in platform engineering

Platform engineering is where YAGNI bites hardest, because “internal developer platforms” are magnets for speculative generality. The golden path is real; the tenth supported language, the optional policy engine, the self-service everything — often isn’t, on day one.

A concrete pattern:

# Good: solve the real, current need (one paved path)
deploy:
  environment: production
  strategy: rolling

# YAGNI smell: five strategies "in case," none required yet
deploy:
  strategy: { type: rolling, canary, blue-green, shadow, a-b }
  plugins: [plugin-registry, custom-adapters, experimental]
  future_flags:
    multi_region: false
    tenant_isolation: false

Ship the rolling strategy. When a canary requirement lands from a real service, add that one. The interface can stay open; the code doesn’t have to.

The same applies to infrastructure. Don’t provision a multi-region, active-active database cluster because “scale will need it.” Run a single healthy region, monitor it, and let a measured threshold — not a fear — trigger the expansion.

When YAGNI does NOT apply

The principle has boundaries, and ignoring them is its own failure mode:

• Compliance and safety. If a regulator or a security baseline requires it now, it’s a current requirement. Build it.
• Irreversible decisions. Choosing a bad data store or a wrong network topology is expensive to undo. Spend design effort here — YAGNI is about code you can add later cheaply, not about skipping due diligence on a one-way door.
• Public APIs and protocols. Once you publish a contract, removing it is a breaking change. Stable, minimal APIs are a different game from internal speculative features.

The test: can I add this later without rewriting the world? If yes, defer it. If no, that’s not YAGNI territory — that’s architecture.

A practical checklist

Before you write the “just in case” code, ask:

1. Is there a current, concrete requirement? Ticket, user story, or real dependency — not a hunch.
2. Could I add this later at similar cost? If the seam is cheap to keep open, defer the implementation.
3. Am I solving a one-way-door decision? If undoing it is brutal, design now; don’t YAGNI the diligence.
4. Does this have a test that represents a real behavior? No real test → probably no real need.
5. What am I not shipping because I’m building this? Opportunity cost is the honest scoreboard.

What I learned

YAGNI isn’t laziness and it isn’t shortsightedness — it’s respect for the cost of code. The cheapest, fastest, most reliable feature is the one you didn’t write because nobody needed it yet. In platform engineering especially, the discipline to ship the paved path and only the paved path is what keeps a platform adoptable instead of overwhelming.

Build the thing the requirement asks for. Keep the door open for the rest. And when the real need arrives — and it will, differently than you imagined — you’ll be glad the code you maintain is the code that actually runs.