YAGNI
Also known as: You Aren't Gonna Need It
XP principle: don't build functionality until it's actually required.
YAGNI ('You Aren't Gonna Need It', or sometimes 'Ya Ain't Gonna Need It') is a principle from Extreme Programming articulated by Ron Jeffries and Kent Beck in the late 1990s, holding that programmers should not build functionality until it is actually required by current concrete needs rather than anticipated future needs. The argument is empirical: features built speculatively for anticipated future needs frequently turn out to differ from actual future needs when those arrive, so the speculative work is wasted while also adding maintenance burden, complexity, and the risk of constraining future design choices. Martin Fowler's 2015 'Yagni' article distinguishes the cost of build (initial development), cost of delay (interest paid on the speculative feature), cost of carry (ongoing maintenance), and cost of repair (correcting bad speculation), arguing the costs typically dominate the value of speculative features. YAGNI complements KISS and Beck's other XP practices, and stands in productive tension with thoughtful upfront design — the principle is not against thinking ahead, but against building ahead.
Core components
- Don't build functionality until concrete current need
- Distinction between thinking ahead (good) and building ahead (often bad)
- Four cost categories (Fowler): cost of build, cost of delay, cost of carry, cost of repair
- XP context with frequent releases enabling deferred decisions
- Connection to evolutionary and emergent design
- Tension with comprehensive upfront design
Primary use case
Code review and design heuristic; agile and XP development practice; refactoring and feature-prioritization guidance; teaching tool for distinguishing speculative from required complexity; complement to KISS and DRY in software craftsmanship.
Common criticisms
- Some forward-looking architectural decisions have substantial path-dependence costs and can't be deferred without major rework — YAGNI applied dogmatically to architectural choices can produce costly rework
- works best when refactoring is cheap and frequent, less well in environments with high deployment friction
- some fields (security, compliance, performance) require anticipating needs that current concrete demand doesn't reveal
- can be invoked to dismiss legitimate concerns about future maintainability
- balance with thoughtful upfront design is genuinely difficult and depends on context that the principle doesn't articulate
- the principle's dogmatic application has been argued to produce technical debt that shows up later as accumulated under-engineering.
Lineage
- Child of
- Extreme Programming
- Siblings
- DRY, KISS, SOLID Principles
- Derived from
- Extreme Programming