YAGNI Principle

Reference: Extreme Programming Explained (Beck), Tidy First? (Beck), Software Engineering at Google (Winters et al.)

When to Apply

• Evaluating whether to build functionality that is not yet needed
• Reviewing code for speculative abstractions, unused extension points, or premature generalization
• Deciding between building flexibility now vs adding it when needed
• Resolving tension between YAGNI simplicity and SOLID extensibility
• Assessing whether the codebase has the supporting practices to apply YAGNI safely

Core Principle

"Always implement things when you actually need them, never when you just foresee that you need them." — Ron Jeffries

YAGNI originated from Extreme Programming in the late 1990s. Kent Beck and Chet Hendrickson, working on the Chrysler C3 project, found that every proposed future capability turned out to be unnecessary — hence, "You Aren't Gonna Need It."

Critical caveat: YAGNI requires supporting practices — continuous refactoring, automated testing, and CI. Without these, YAGNI leads to disorganized code. YAGNI means "don't build it yet," not "don't build it well."

The Four Costs of Unnecessary Complexity

Martin Fowler's analysis of what you pay when you build speculatively:

Studies show only about one-third of features actually improve the metrics they target (Kohavi et al., Microsoft analysis of thousands of A/B tests).

What YAGNI Applies To

YAGNI Violations (Do NOT Build)

• Features no user has requested based on "what if they want..."
• Abstract factories, plugin systems, or strategy patterns with only one implementation
• Configuration options for hypothetical future flexibility
• Database columns for anticipated but unconfirmed requirements
• API endpoints for features that don't exist yet
• Generic frameworks extracted from a single use case

NOT YAGNI Violations (These Are Good Practice)

• Clean code structure (SRP, meaningful names, small functions)
• Automated tests for existing functionality
• Proper error handling for current operations
• Security measures for current features
• Documentation of current behavior
• Refactoring existing code for clarity

Fowler's key distinction: "YAGNI only applies to capabilities built into the software to support a presumptive feature. It does not apply to effort to make the software easier to modify."

The YAGNI-SOLID Tension

The apparent conflict: YAGNI says don't build what you don't need; SOLID/OCP says make things extensible.

Fowler's Resolution

Being easy to extend is a property of well-structured code. Being already extended is speculative engineering.

Fowler's Practical Test

"Imagine the refactoring you'd have to do later to add this feature. Is it significantly more expensive to add later than now?"

• If refactoring later is cheap → don't build it now
• If refactoring later is genuinely expensive (e.g., database schema migration affecting millions of rows) → consider building it now
• In most cases, the refactoring is cheaper than you think

Decision Framework

When tempted to build something preemptively:

1. Is there a confirmed, current need? If yes, build it. YAGNI doesn't apply to known requirements.
2. Is it structural quality or speculative capability? Clean code, tests, and good naming are NOT YAGNI violations. Only speculative features and extension points are.
3. Apply the refactoring thought experiment. How expensive would it be to add this later when you actually need it? If the answer is "not much more expensive," wait.
4. Check for supporting practices. YAGNI is safe only with automated tests, CI, and a culture of continuous refactoring. Without these, you need more upfront design.
5. Are you building a framework from a single use case? If so, stop. You need at least three concrete use cases to know the right abstraction.

Common Pitfalls

YAGNI at Scale

At Google scale (Software Engineering at Google), YAGNI manifests as:

• Simple designs that evolve — start with the simplest architecture; evolve as traffic and complexity grow
• Incremental infrastructure — build infrastructure for current scale, not predicted future scale
• Feature flags over speculative features — ship code behind flags; enable when ready
• Monorepo simplicity — avoid premature decomposition into microservices; a monolith is fine until proven otherwise

Checklist

When reviewing code or proposals for YAGNI compliance, verify:

• Every feature addresses a confirmed, current need — not a speculative "might need"
• Abstractions (interfaces, factories, plugin systems) have at least two concrete implementations
• No configuration options exist for hypothetical flexibility
• Structural quality (clean code, tests, good names) is maintained — YAGNI doesn't excuse poor design
• The refactoring thought experiment shows it's not significantly more expensive to add later
• Supporting practices are in place: automated tests, CI, continuous refactoring
• The simplest solution that meets current requirements has been chosen

Key References

Online References

• Martin Fowler, "Yagni" (bliki, 2015)
• Ron Jeffries, "YAGNI, yes. Skimping, no. Technical Debt? Not even."