You Aren't Gonna Need It (YAGNI)

Build a capability when a real requirement needs it, not when you foresee that one might. Keep the code easy to change instead.

Overview

YAGNI stands for You Aren't Gonna Need It. It comes from Extreme Programming (XP). Ron Jeffries' 1998 article states it in one line: always implement things when you actually need them, never when you just foresee that you need them. Martin Fowler traces the phrase to Kent Beck telling Chet Hendrickson, on the C3 project, that a feature he was about to build was not going to be needed.

The principle exists because guessed features are usually wrong, and even the right ones cost money from the day they are written. Jeffries' own reasoning is practical: speculative work pulls attention from what is needed now, spends time and code on a hypothetical, and the guess often never comes true. The best way to write code quickly and with fewer bugs is to write less of it.

Build it when a requirement asks for it

A feature is in the current iteration — Build it — It is needed
A feature might be asked for next quarter — Do not build it; keep the code easy to change — The guess may be wrong, and it costs from today
A refactoring makes the next change easier — Do it — This is not a feature; YAGNI does not apply
A test protects existing behavior — Write it — Same: an enabling practice, not a presumptive feature

What a presumptive feature costs

Fowler's 2015 note on YAGNI names four costs of a feature built before it is needed. Together they explain why 'it is cheap to add now' is rarely true.

Cost of build — Analysis, programming and testing of a feature nobody needs yet — Now
Cost of delay — The needed feature that shipped later because this one took the time — Now
Cost of carry — Extra code that slows down every other change while it sits there — Every day until it is needed or removed
Cost of repair — Rework when the need arrives shaped differently, or the code has rotted — Later, if the need ever arrives

What YAGNI does not mean

YAGNI is about presumptive features, not about code quality. Fowler is explicit that it does not apply to effort that makes the software easier to modify, and that it is not a reason to neglect the health of the code base. Refactoring, tests and clean boundaries are what make on-demand building possible.

A second payment provider when only one is in use — Putting the one provider behind a small, clear interface
Configuration for values nobody changes — Naming the value as a constant
A plugin system with one plugin — Keeping the one plugin's code in its own module
Generic 'framework' code for future projects — Tests that let you change today's code safely
Extra database columns 'while we are at it' — A migration tool so adding a column later is routine

What you will be able to do

State YAGNI with its origin and its exact scope: capabilities, not code quality.
Name the four costs of a presumptive feature and apply them to a real example.
Tell good preparation (easy to change) from a violation (already changed).
Decide when building ahead is justified and defend that decision.
Handle a stakeholder who wants features built just in case.

Interview questions

How do you tell good preparation from a YAGNI violation?
What does a speculative feature actually cost?
How does YAGNI fit with the SOLID principles, especially open/closed?
When is it right to build ahead of the requirement?
How do you handle a stakeholder who wants features built just in case?