"We'll need to support multiple currencies eventually, so let's build the abstraction now." That instinct feels responsible and is usually wrong. Kent Beck's answer, coined during the Chrysler C3 project, became one of the most useful three-word principles in software: you aren't gonna need it. Martin Fowler later spelled out exactly what building it early costs you, and the bill comes in three parts.
Key Takeaways
- YAGNI says don't build presumptive features for needs that haven't materialized (Fowler on Yagni).
- Premature features cost three ways: cost of building, cost of delay, and cost of carry (Fowler).
- Even when you're sure you'll need it, what you actually need usually turns out different (Fowler).
- Fowler named the related code smell speculative generality in Refactoring.
The Three Costs
Fowler's analysis is the part worth internalizing, because most people only count the first cost (Yagni).
Cost of building. The obvious one: the analysis, code, and tests that go into a feature nobody has asked for yet.
Cost of delay. Less obvious and often larger. Every week spent on the speculative feature is a week not spent on something customers want now. You paid in opportunity as well as hours.
Cost of carry. The sneakiest. The speculative abstraction sits in your codebase making everything harder: more code to read, more paths to test, more complexity for every future change, forever. It charges rent even while unused.
| The cost you count | The costs you forget |
|---|---|
| Building it | Delaying what customers want |
| The ones you don't | Carrying the complexity forever |
| One-time effort | Ongoing drag on every change |
Why You Usually Guess Wrong
The strongest part of the argument is about accuracy. As Fowler puts it, even when you're completely sure you'll need a capability later, you should still wait, because it usually turns out either that you don't need it at all, or that what you actually need is meaningfully different from what you predicted (Yagni). Requirements arrive with details nobody imagined, so the abstraction you built in advance often fits the real need badly, and now you have to unwind it and build the right thing.
The resulting design flaw has a name from the code-smells catalogue in Refactoring (Fowler with Kent Beck): speculative generality, machinery built for scenarios that never arrived. Fowler's own write-up of the principle is the canonical reference (Yagni).
A Concrete Version
A team building an internal tool adds a plugin architecture on day one, because "other teams will want to extend this." It takes three weeks and complicates every subsequent change, since all features must now route through the plugin abstraction. Eighteen months later, exactly zero plugins exist. When another team finally does want to extend it, their requirement doesn't fit the plugin model at all, so it gets rebuilt. The three weeks were the small loss; the eighteen months of carrying an unused abstraction through every change was the big one.
The Honest Counterpoint
YAGNI is genuinely dangerous when applied to the wrong category of decision. It works well for features and speculative abstractions, which are cheap to add later. It applies much less to decisions that are expensive or near-impossible to reverse: your data model, your security architecture, whether you can support multi-tenancy, basic scalability assumptions. Deciding "we aren't gonna need encryption at rest" or skipping any thought about data partitioning is not YAGNI; it's negligence with a slogan attached. The useful distinction is reversibility: apply YAGNI hard to things you can add later at similar cost, and think ahead about things you can't.
What This Means for Teams
YAGNI connects directly to the finding that most features go unused: if the majority of what you build on request goes untouched, the stuff you build on speculation fares worse. It also pairs with choosing boring technology and resisting premature microservices. The common thread is a senior instinct for what not to build, which conserves your scarcest resource for the things customers actually asked for. See available engineers.
Frequently Asked Questions
What does YAGNI mean?
"You aren't gonna need it," a principle coined by Kent Beck saying you shouldn't build presumptive features for needs that haven't materialized yet.
What are the three costs of building early?
Fowler identifies the cost of building (effort spent), the cost of delay (what you didn't build instead), and the cost of carry (the complexity the feature adds to every future change).
What if I'm certain we'll need it later?
Fowler's point is that certainty doesn't help much: usually you either don't need it after all, or what you actually need differs from what you predicted, so the early version fits badly.
When should I ignore YAGNI?
For decisions that are expensive or impossible to reverse, like data models, security architecture, and core scalability assumptions. Apply YAGNI to things you can add later at similar cost.
The Bottom Line
Building for an imagined future costs you three times: the build, the delay, and the complexity you carry forever. And you usually guess wrong about what's needed anyway. Apply YAGNI hard to features and speculative abstractions, think ahead on the decisions you can't reverse, and spend the saved capacity on what customers are asking for today.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
