YAGNI: the principle I needed at 19

At 19, I built a configuration system for a project because I was convinced the app would eventually need to be multi-tenant with per-client settings. The app never had more than one client. The configuration system added two weeks of development time and about three months of complexity to maintain.

YAGNI—You Aren't Gonna Need It—is the principle that saved me from myself.

What It Actually Says

YAGNI says: don't build features or abstractions for requirements that don't exist yet. Not 'don't think about the future'—just 'don't build for it before you need to.'

The future is uncertain. Your guess about what you'll need in six months is usually wrong. And code you write today has a cost: it has to be read, understood, maintained, and worked around by every developer who comes after you.

The Patterns That Violate It Most

The generic plugin system for an app with one integration and no plans for more.

The multi-level abstraction around a single database table because 'we might switch databases.'

The configuration flag for behavior that will never be anything other than the default.

// This is YAGNI:
class PaymentProcessor
{
    public function process(string $provider, array $data): Receipt
    {
        return match($provider) {
            'stripe'  => $this->processStripe($data),
            'paypal'  => $this->processPaypal($data),  // No PayPal integration exists
            'revolut' => $this->processRevolut($data), // Or Revolut
        };
    }
}

// This is correct:
class StripePaymentService
{
    public function charge(array $data): Receipt { ... }
}

The Hard Part

The hard part isn't the rule. It's that the imagined future requirement always feels real. The trick is to ask: do we have a concrete, scheduled need for this? Not 'might we someday'—but 'do we have a ticket, a customer, a deadline?' If no, don't build it.

Simple code is not lazy code. It's disciplined code.