YAGNI

YAGNI is the habit of refusing work you cannot justify with a present requirement. Teams that treat it as a joke about laziness miss the point. It is a bet that your forecast of the future is worse than your ability to ship when the future arrives.

You aren’t going to need it.

Kent Beck used that line on the C3 project when Chet Hendrickson pitched capabilities the system would need soon. The phrase stuck as YAGNI (“You Aren’t Gonna Need It”), a mantra from Extreme Programming and a sharp cousin of simple, incremental design. Martin Fowler’s Yagni bliki walks through the economics; the c2.com wiki page on the rule is where many of us first met the name.

A presumptive feature is any code written to support a capability you are not exposing yet. Gall’s law is the architectural version of the same mistake from the other direction. A complex system designed from scratch rarely becomes trustworthy. The classic trap is building piracy pricing into the engine because sales will need it in six months, while storm pricing is the job on the board today. YAGNI says ship what the backlog demands now and add piracy when someone is ready to sell it.

That rule applies to user-visible behavior and to abstractions you add “for flexibility.” Parameterizing for every risk class you can name often makes the code harder to read for the risk you are pricing this week. You are not forbidden to abstract. You are on the hook to show the abstraction pays for itself on today’s path, not on a slide deck.

Fowler groups the damage into a few buckets that show up on real roadmaps.

Build cost. Analysis, coding, and tests for a feature that never ships is pure waste. Even careful upfront requirements work leaves a large share of shipped features that do not move the metrics they were meant to move.

Cost of delay. Effort spent on presumptive work is effort not spent on the feature that could earn revenue or learning now. Two months building unused pricing logic is two months you did not put storm insurance in front of customers.

Cost of carry. The speculative code stays in the tree. It complicates every change until you need it or delete it. Extra branches, flags, and extension points slow reviews and debugging for unrelated work. Fowler’s reminder is worth keeping in mind: an extensibility point nobody uses is not free storage. It is friction you drag on every pass.

Built wrong anyway. Teams learn. When the need finally appears, the shape you guessed six months ago rarely matches what you now know about users and the code. You either refactor or route around the old guess. That is the same family of pain as technical debt, except you took on the debt before you had a customer for the asset.

YAGNI is obvious on big features and easy to violate in an hour. Adding a field “we will need soon,” a plugin hook with one implementation, or a regex feature your highlighter does not use yet all raise carry cost. None of them show up on the roadmap as a presumptive epic. They still add up.

YAGNI targets capabilities you are not using yet. It is not permission to let the codebase rot.

Refactoring, automated tests, and continuous delivery are how you keep change cheap enough for deferral to work. Fowler treats those as enabling practices for evolutionary design, not violations of the rule. If the code is hard to change, “we will add it later” becomes a trap.

Likewise, work that does not increase complexity for current readers is outside the argument. A table lookup instead of a magic string may be worth doing now because it clarifies today’s code, not because you are betting on i18n next quarter.

I treat YAGNI as a default until evidence says otherwise. You will sometimes pay more to add a capability late than you would have paid to seed it early. Those cases are easier to spot in hindsight than in planning. The wins (less carry, faster delivery of what matters now, fewer wrong guesses frozen into APIs) tend to dominate on teams that can refactor without a release calendar.

When someone says “we should build it now so we do not have to rebuild later,” I ask them to walk through the later change out loud. Often the incremental cost is smaller than the calendar and complexity tax of carrying the feature until the need is real. When the cost of delay is genuinely high and the need is well grounded, build it. Just do not confuse preparation with a forecast that has not earned its keep.