Practical guidance and examples to help teams focus on current requirements and avoid wasted effort.
Introduction
YAGNI stands for "You Aren't Gonna Need It". It is a software development dictum that discourages building functionality before it is actually required. The aim is to reduce wasted effort, keep code simple, and deliver business value faster.
What is YAGNI?
Coined in the context of Extreme Programming (XP), YAGNI advises developers to implement only what is necessary for current requirements. Rather than predicting future needs and building generic abstractions up front, prefer incremental changes driven by real use-cases.
Why YAGNI matters
- Reduces wasted work: unnecessary features cost time to implement and maintain.
- Speeds delivery: focus on current priorities and ship value sooner.
- Prevents over-engineering: avoids complex abstractions that are never used.
- Improves clarity: less code means fewer places for bugs to hide.
Common scenarios of premature work
- Building generic frameworks or plugin systems before there are two distinct implementations.
- Introducing caching, batching, or parallelism when the current load is low and unmeasured.
- Creating complex configuration systems for options that may never be changed.
- Abstracting small differences across modules before those differences actually diverge.
Examples: premature vs pragmatic
Premature abstraction (bad)
// A team creates an elaborate factory and plugin system for exporting reports
// but only ever needs one report format and never gets other providers.
interface ReportExporter { void export(Report r); }
class ExporterFactory { /* complicated registry */ }
// Many classes and layers for a single implementation
Pragmatic approach (good)
// Start with a single, simple exporter and extract an interface only when a second implementation exists
class CsvReportExporter {
void export(Report r) { /* write CSV */ }
}
// When a second exporter (e.g., PdfReportExporter) becomes necessary,
// extract ReportExporter and refactor tests and usage accordingly.
Premature optimization (bad)
// Adding complex caching with async invalidation before measuring performance
// This adds bugs and complexity for little or no benefit.
Measure-driven optimization (good)
// Profile the system, identify hotspots, then add targeted caching or batching with tests and metrics.
Balancing YAGNI with good design
YAGNI doesn't mean being careless. You can be pragmatic while keeping the codebase ready for change:
- Write clean code: clear names and small functions make later refactoring easier.
- Keep tests comprehensive: tests make refactoring safer when abstraction becomes necessary.
- Prefer simple abstractions: if you must prepare for change, choose low-cost, well-understood abstractions.
- Document intent: add notes (TODOs) where you intentionally deferred a more generic solution.
When not to follow YAGNI
There are scenarios where preparing ahead is justified:
- Platform constraints: when the platform/API enforces a design that requires upfront work.
- Security & compliance: regulatory requirements that must be met from day one.
- High cost of change: making future changes is extremely expensive or risky (e.g., distributed protocols).
- Known future requirements: when stakeholders can reliably confirm upcoming needs that are costly to retrofit.
Conclusion & further reading
YAGNI is a practical reminder to focus on delivering real value and avoiding speculative complexity. Combine YAGNI with KISS (Keep It Simple) and DRY (Don't Repeat Yourself) to produce code that is lean, maintainable, and easy to evolve. When requirements change, refactor incrementally and rely on tests to keep behavior intact.
Further reading: Extreme Programming literature, The Pragmatic Programmer, and modern agile engineering blogs on incremental design.
0 Comments