YAGNI
Also Known As
You Aren't Gonna Need It
YAGNI principle
no speculative features
TL;DR
You Aren't Gonna Need It — don't implement functionality until it's actually required.
Explanation
YAGNI is an Extreme Programming principle arguing that developers should not add functionality based on speculation about future needs. Premature generalisation creates dead code, complicates maintenance, and often builds the wrong abstraction — requirements change and the speculative feature is never used or is removed. Implement the simplest thing that works for current requirements. Refactor to accommodate new requirements when they actually arrive — by then you'll have more information to design correctly.
Common Misconception
✗ YAGNI means writing the minimum code possible and never thinking ahead. It means not building features until they are actually required — thinking ahead about architecture and extensibility is still valuable; building unasked-for features is what YAGNI discourages.
Why It Matters
You Aren't Gonna Need It prevents speculative complexity — every abstraction that turns out to be wrong adds maintenance cost without ever delivering value, and the code that isn't written can't have bugs.
Common Mistakes
- Designing plugin systems, configuration layers, or factory hierarchies for a single use case.
- Adding method parameters for 'future options' that never materialise.
- Implementing multiple output formats (JSON, XML, CSV) when only JSON is currently needed.
- Confusing YAGNI with not writing tests — tests for current requirements are not speculative.
Avoid When
- Core infrastructure decisions (database schema, API contracts, auth) where retrofitting is expensive — some upfront design is justified.
- Security — do not defer input validation, auth checks, or encryption on the grounds that attacks may not happen.
- Accessibility and internationalisation in consumer products — retrofitting is far more expensive than building in from the start.
When To Use
- Feature development — do not build configurability, plugins, or extension points until a real need exists.
- Abstractions — do not create interfaces or base classes for a single implementation that may never have a second.
- Performance optimisation — do not optimise before profiling shows an actual bottleneck.
- Resisting stakeholder requests to 'just add a flag for that' — every flag is future complexity.
Code Examples
✗ Vulnerable
class UserRepository {
// Built 'just in case' — never called
public function findByAstrologicalSign(string $sign): array { ... }
public function exportToExcel(): string { ... }
public function importFromLegacyCsv(): void { ... }
}
✓ Fixed
class UserRepository {
public function findById(int $id): ?User { ... }
public function findByEmail(string $email): ?User { ... }
public function save(User $user): void { ... }
// Add methods when a real feature requires them
}
References
Tags
🤝 Adopt this term
£79/year · your link shown here
Added
15 Mar 2026
Edited
25 Mar 2026
Views
30
🤖 AI Guestbook educational data only
|
|
Last 30 days
Agents 1
No pings yesterday
Amazonbot 9
Google 5
Perplexity 3
Unknown AI 2
Ahrefs 2
ChatGPT 2
Majestic 1
SEMrush 1
Also referenced
How they use it
crawler 21
crawler_json 4
Related categories
⚡
DEV INTEL
Tools & Severity
🔵 Info
⚙ Fix effort: Low
⚡ Quick Fix
Delete the feature/abstraction/flexibility that no current requirement needs — if it is needed later, add it then with full context
📦 Applies To
PHP 5.0+
web
cli
queue-worker
🔗 Prerequisites
🔍 Detection Hints
Plugin system for an app with one plugin; generic framework built for one use case; unused flexibility parameters
Auto-detectable:
✗ No
⚠ Related Problems
🤖 AI Agent
Confidence: Low
False Positives: High
✗ Manual fix
Fix: High
Context: File
Tests: Update