YAGNI — You Aren't Gonna Need It: resist building for hypothetical futures

Definition

YAGNI — You Aren't Gonna Need It — is the principle that you should not implement functionality until it is actually required. Building things in advance for anticipated but unconfirmed future needs creates code that must be maintained, documented, and tested even when it is never used. The cost of speculative generality is always paid; the benefit is usually not.

In Practice

<?php
// YAGNI violation: building a multi-tenancy system when the product has one client
interface TenantResolver
{
    public function resolve(Request $request): Tenant;
}

class SubdomainTenantResolver implements TenantResolver { /* ... */ }
class HeaderTenantResolver implements TenantResolver { /* ... */ }
class PathTenantResolver implements TenantResolver { /* ... */ }

// The product has one company using it. This took a week to build and test.
// When the real multi-tenancy requirement arrived 8 months later,
// the architecture had changed and this code was deleted anyway.

// YAGNI-compliant: solve the actual problem you have today
class UserRepository
{
    public function findById(int $id): ?User
    {
        return User::find($id);
    }
}

// If multi-tenancy becomes real, introduce the abstraction then —
// you'll have concrete requirements to guide the design.

YAGNI is hardest to follow under pressure to "make the code extensible". Extensibility is a virtue, but extension points have a cost: they add indirection, require maintenance, and must be documented. The correct approach is to write code that is easy to change (through good naming, clear structure, and low coupling) rather than code that is pre-built for anticipated changes. Code that is easy to change can accommodate the real future requirement when it arrives.

In Context

YAGNI comes up in design discussions and code reviews. The prompt is often "Shouldn't we build this more generically in case we need to support X later?" The YAGNI response is: "Let's wait until we actually need X — we'll design it better with real requirements than with hypothetical ones." Martin Fowler frames this as the cost of carrying dead code vs the cost of a refactor when the need becomes real.

The subtlety: YAGNI does not mean writing throw-away code or ignoring quality. It means not building features, abstraction layers, or configuration options for requirements that haven't been specified. A clean, simple implementation of what is actually needed today is both YAGNI-compliant and professionally written code.

Related terms: KISS (the partner principle about structural simplicity), speculative generality (the code smell YAGNI guards against, named in Martin Fowler's refactoring catalog), technical debt (somewhat ironically, YAGNI violations create a kind of technical debt — dead code and unused abstractions that must be maintained), and refactoring (the mechanism for adding structure when the real requirement arrives).