YAGNI Principle

You Aren’t Gonna Need It — an Extreme Programming principle that states a programmer should not add functionality until it is actually needed. Coined by Ron Jeffries, YAGNI is a direct response to the common tendency to build for imagined future requirements that often never materialize.

The cost of speculative features is not just the time to build them — it is the ongoing maintenance, testing, and cognitive overhead they impose on every future change. Studies consistently show that the majority of speculative features are never used, making them pure waste.

Key Principles

Build for today’s requirements. If the current task does not require a feature, do not build it. This includes: configuration options nobody asked for, plugin architectures with one plugin, abstract base classes with one implementation, and database columns for “future use.”

The cost of wrong abstractions. Speculative code is built without the context of actual use. When the real requirement arrives, it rarely matches the speculation — and now you have legacy code to work around instead of a clean slate to build on.

When YAGNI does not apply:

• Security — always build in security from the start
• Core architectural decisions that are expensive to change later (database choice, API boundaries)
• Contractual or regulatory requirements with known deadlines

Example

// YAGNI violation: building for hypothetical multi-tenancy
class UserService {
  constructor(private tenantId: string) {}
  getUser(id: string) {
    return db.query('SELECT * FROM users WHERE id = ? AND tenant_id = ?', [id, this.tenantId]);
  }
}
 
// YAGNI-compliant: build multi-tenancy when you actually have multiple tenants
class UserService {
  getUser(id: string) {
    return db.query('SELECT * FROM users WHERE id = ?', [id]);
  }
}

Relationship to Other Principles

YAGNI and KISS are complementary — YAGNI controls scope (what to build), KISS controls implementation (how to build it). Together they prevent both feature bloat and implementation bloat.

YAGNI can appear to conflict with DRY — extracting a shared abstraction “for future use” is speculative. Apply DRY only when duplication actually exists, not when you predict it will.

Common Mistakes

• Using YAGNI to justify skipping error handling, logging, or security
• Confusing YAGNI with “don’t plan ahead” — architectural foresight is different from speculative implementation
• Applying YAGNI to infrastructure (monitoring, backups) that is always needed

References

• Jeffries, R. (1998). You Aren’t Gonna Need It. XProgramming.com.
• Beck, K. (2004). Extreme Programming Explained. 2nd Edition.