YAGNI
You Aren’t Gonna Need It
1. Overview of YAGNI, the Extreme Programming Principle Against Speculative Generality
flowchart LR
A["Building for<br/>imagined future needs"] --"Applying<br/>YAGNI"--> B["Implement only<br/>what's required now"] --"Result"--> C["Simpler, more<br/>maintainable codebase"]
style A fill:#FFEBEE,stroke:#D32F2F,color:#000
style B fill:#E3F2FD,stroke:#1976D2,color:#000
style C fill:#E8F5E9,stroke:#388E3C,color:#000
Definition: An Extreme Programming (XP) principle, coined by Ron Jeffries, stating that a developer should not add functionality until an actual, concrete requirement demands it.
- Targets speculative generality: interfaces, config flags, and abstraction layers built for hypothetical future use cases.
- Works together with the XP practices of TDD and continuous refactoring rather than as a standalone rule.
Characteristics:
- (Cost deferral) The cost of building unneeded flexibility is paid immediately, in complexity and code to maintain, while the benefit — if it ever arrives — is uncertain and delayed.
- (Tension with DRY) Applied too early, YAGNI can conflict with DRY: a shared abstraction extracted before a second real use case exists is itself a YAGNI violation.
- (Depends on a refactoring safety net) YAGNI is only safe when the codebase has enough test coverage to refactor confidently once the “not yet needed” feature actually becomes needed.
2. Core Mechanism and Application of YAGNI
A. Speculative Generality vs. the Simplest Thing That Could Possibly Work
flowchart LR
A["New requirement"] -->|"Speculative design<br/>(anticipate future variants)"| B["Over-engineered code<br/>(unused flexibility)"]
A -->|"YAGNI<br/>(solve only the current case)"| C["Simplest working code"]
style B fill:#FFEBEE,stroke:#D32F2F,color:#000
style C fill:#E8F5E9,stroke:#388E3C,color:#000
| Category | Speculative Generality (Anti-pattern) | YAGNI-Compliant Response |
|---|---|---|
| Interfaces | Extract an interface for a class with a single implementation “in case another one is needed” | Keep the concrete class; extract an interface when a second implementation actually appears |
| Configuration | Add config flags/parameters for behavior nobody has asked to vary | Hard-code the current behavior; parameterize when a real variant is requested |
| Abstraction layers | Build a generic plugin/strategy framework for one known use case | Write the direct solution; generalize after the same pattern repeats (Rule of Three) |
| Data model | Add nullable columns/fields for attributes no feature uses yet | Add the field in the same change that introduces the feature needing it |
B. Relationship to TDD and Refactoring
flowchart LR
T1["Red<br/>write a failing test<br/>for the current case"] --> T2["Green<br/>simplest code<br/>that passes it"] --> T3["Refactor<br/>remove duplication<br/>only as it appears"]
T3 -->|"Next real requirement"| T1
style T2 fill:#E3F2FD,stroke:#1976D2,color:#000
style T3 fill:#E8F5E9,stroke:#388E3C,color:#000
| Practice | Relationship to YAGNI | Practical Guidance |
|---|---|---|
| TDD (Red-Green-Refactor) | “Green” step is YAGNI in action — write only enough code to pass the current test | Resist adding logic the test doesn’t require, even if it “seems obviously needed next” |
| Refactoring | Supplies the safety net that makes deferring generality safe | Keep test coverage high so a design can be extended later without fear |
| Rule of Three | Draws the line for when generalization stops being speculative | Extract an abstraction on the third duplication, not the first |
| Emergent design | YAGNI lets architecture emerge from real requirements instead of upfront prediction | Revisit and simplify designs regularly rather than locking in an early guess |
3. Expected Benefits and Application of YAGNI
| Category | Key Expected Benefit | Practical Application |
|---|---|---|
| Development speed | Less code to write and review for each requirement | Question any interface, flag, or parameter that has no current caller |
| Maintenance cost | Fewer unused code paths to understand, test, and keep working | Delete speculative code found during review instead of leaving it “just in case” |
| Team dynamics | Reduces debate over hypothetical future requirements during design review | Anchor design discussions to the requirement in front of the team, not imagined ones |
| Risk of misuse | Guards against being used to justify skipping necessary error handling or security controls | Apply YAGNI to speculative features only, never to known correctness, security, or accessibility requirements |