What is the YAGNI Principle?
Learn the YAGNI principle — avoiding speculative generality, real costs of unused code — with a Java example and interview Q&A.
Expected Interview Answer
YAGNI, short for "You Aren’t Gonna Need It," is the design principle that a developer should not add functionality, flexibility, or abstraction until it is actually required by a present, concrete requirement, rather than building it speculatively for an imagined future need.
It originated from Extreme Programming and pushes back directly against speculative generality — the temptation to add configuration options, plugin hooks, or extra abstraction layers because a feature "might be needed later." The cost of unused speculative code is real: it must still be written, tested, documented, and maintained, and it often turns out to be wrong once the actual future requirement arrives, requiring rework anyway. YAGNI does not argue against good design or reasonable extensibility where a requirement is already known; it argues specifically against paying complexity costs today for benefits that may never materialize. Applied well, YAGNI keeps a codebase focused on what is proven necessary, and new capability is added exactly when a real requirement demands it, guided by refactoring rather than upfront speculation.
- Avoids wasted effort building features nobody ends up needing
- Keeps the codebase smaller and easier to maintain
- Reduces the chance of building the wrong abstraction speculatively
- Lets the team focus effort on requirements that are actually confirmed
AI Mentor Explanation
A club builds a single well-maintained practice net for the season instead of constructing five specialized nets for bowling styles no one on the roster currently uses. If a spin specialist ever joins, that net can be built then, with a clear, real need driving its design. That is YAGNI: build the capability when a concrete requirement actually shows up, not speculatively ahead of time based on a guess.
Step-by-Step Explanation
Step 1
Confirm the requirement is real
Check whether a capability is demanded by an actual, current requirement or is merely anticipated.
Step 2
Resist speculative generality
Do not add configuration options, hooks, or abstraction layers for imagined future needs.
Step 3
Build the simplest thing that satisfies today's need
Implement exactly what the confirmed requirement calls for, nothing more.
Step 4
Add capability when the need becomes real
Extend the design later, guided by the actual new requirement, using refactoring rather than upfront guessing.
What Interviewer Expects
- A correct statement of YAGNI: do not build for speculative future requirements
- Understanding of the real cost of unused speculative code (build, test, maintain)
- Awareness that YAGNI does not mean avoiding all good design or planning
- Ability to give a concrete example of over-engineering that YAGNI would prevent
Common Mistakes
- Using YAGNI as an excuse to write sloppy, unmaintainable code
- Confusing YAGNI with refusing to plan or design at all
- Not recognizing when a requirement is already confirmed versus merely speculative
- Applying YAGNI to skip essential error handling that the current requirement actually needs
Best Answer (HR Friendly)
“YAGNI means I don’t build functionality or flexibility until there is an actual confirmed need for it, rather than guessing what might be useful someday. Speculative features still cost time to build, test, and maintain, and they are often wrong once the real requirement shows up anyway, so I prefer to add capability when it is genuinely needed and let refactoring handle the rest.”
Code Example
// Violates YAGNI: a generic plugin system built for a need that doesn’t exist yet
interface NotificationPlugin { void send(String message); }
class NotificationManager {
private java.util.List<NotificationPlugin> plugins = new java.util.ArrayList<>();
void register(NotificationPlugin p) { plugins.add(p); }
void notifyAll(String message) {
for (NotificationPlugin p : plugins) p.send(message);
}
}
// Only ever used with a single email sender in practice — the plugin
// architecture adds complexity for a flexibility need that never materialized.
// Follows YAGNI: build exactly what the current requirement needs
class EmailNotifier {
void send(String message) {
System.out.println("Emailing: " + message);
}
}Follow-up Questions
- How do you distinguish a confirmed requirement from a speculative one during design?
- How does YAGNI relate to KISS and DRY when they seem to pull in different directions?
- What is the real cost of building unused speculative flexibility?
- How does YAGNI fit with agile, iterative development practices?
MCQ Practice
1. YAGNI is best summarized as?
YAGNI specifically targets speculative functionality built ahead of a confirmed, real requirement.
2. What is the real cost YAGNI warns about for unused speculative code?
Speculative code carries real ongoing cost and is frequently wrong once the actual future requirement arrives.
3. YAGNI originated from which methodology?
YAGNI is one of the core principles associated with Extreme Programming.
Flash Cards
YAGNI in one line? — Do not build functionality until an actual, confirmed requirement needs it.
What does YAGNI push back against? — Speculative generality — building flexibility for imagined future needs.
Real cost of speculative code? — It must be built, tested, and maintained, and is often wrong once the real need arrives.
Which methodology is YAGNI associated with? — Extreme Programming (XP).