YAGNI (You Aren't Gonna Need It)
Don't implement features until you actually need them.
Tiny Summary
YAGNI: "You Aren't Gonna Need It." Don't build features for hypothetical future requirements. Build what you need now, add more later if needed.
The Principle
Don't: Add features "just in case," build for imagined future, create abstractions before needed
Do: Build what's required now, add features when actually needed, keep simple until complexity justified
Examples
Over-engineering: Building multi-tenancy, shard routing, cache invalidation for simple database (YAGNI violation). Build simple connection and working code (YAGNI).
Feature creep: Need basic auth → Build OAuth, SAML, 2FA, biometric "just in case" (violation). Build basic auth, add others when customers ask (YAGNI).
Why It Matters
Wasted time: Building unused features takes time. Opportunity cost is real.
Added complexity: More code = more bugs. More abstractions = harder to understand. More features = more maintenance.
Wrong guesses: Future requirements change. You'll guess wrong. Better to wait for real requirements.
When YAGNI Doesn't Apply
Known requirements: "Launching in Europe next month" → Build i18n now. "SOC 2 audit in Q2" → Build logging now.
Expensive to add later: Database migrations (pick right schema), API design (breaking changes costly), security (retrofit hard)
YAGNI Doesn't Mean
Write bad code, ignore obvious extensibility, or paint into corners. It means: Don't add features speculatively, don't build for hypotheticals, keep simple until real requirements emerge.
Key Insights
Most "future-proofing" code never gets used. Requirements change—your guesses will be wrong. Simple code is easier to change later. Build for today, refactor for tomorrow. Related: KISS, Occam's Razor, "Do The Simplest Thing That Could Possibly Work."