YAGNI Principle
YAGNI ("You Aren't Gonna Need It") is a software design principle from Extreme Programming that advises developers not to add functionality until it is actually required, rather than building it speculatively for anticipated future needs.
Definition
YAGNI ("You Aren't Gonna Need It") is a software design principle from Extreme Programming that advises developers not to add functionality until it is actually required, rather than building it speculatively for anticipated future needs.
Overview
YAGNI originated within Extreme Programming (XP) in the 1990s as a counterweight to over-engineering. The core idea is simple: every piece of speculative functionality — a configurable option nobody asked for, an abstraction layer built "just in case" — carries a real cost in code to write, test, document, and maintain, even if it is never used. YAGNI asks developers to defer that cost until the need is proven by an actual requirement. In practice, YAGNI works alongside two other well-known principles: DRY, which discourages duplicating logic, and KISS, which favors simple solutions over clever ones. Together they form a common shorthand for pragmatic, incremental software design. YAGNI is often invoked during code review or refactoring discussions when a proposed abstraction or configuration option has no current caller or use case. The principle does not mean ignoring architecture entirely — it means preferring the simplest design that satisfies today's known requirements, and trusting that refactoring later, when a real need appears, is usually cheaper than guessing wrong now. Teams practicing agile or XP-style development lean on YAGNI to keep codebases smaller, easier to test, and less coupled to assumptions that may never materialize.
Key Concepts
- Originated in Extreme Programming (XP) methodology
- Discourages building features before they are actually needed
- Reduces wasted effort on unused abstractions and configuration options
- Complements DRY and KISS as a core pragmatic design heuristic
- Encourages deferring architectural decisions until requirements are concrete
- Keeps codebases smaller and easier to test and maintain
- Frequently cited during code review to challenge speculative generality