What is YAGNI?
Engineering culture
YAGNI stands for "You aren't gonna need it". It is a software design principle that says you should not build a feature, abstraction, or extension point until there is a real, present need for it. The idea came from Extreme Programming and pushes teams away from speculative design. It is not about being careless or short sighted. It is about keeping software simple now so it can change more easily when the future finally arrives.
What this means
YAGNI is the cultural permission slip many engineers need when they are tempted to build for imaginary futures. Instead of asking "what might this system need one day?", it asks "what do we know we need now?" That sounds almost too simple, which is part of why the phrase survived.
The principle is blunt because overbuilding is common. Teams often add options, hooks, roles, generic data models, or architecture "for later". Later may arrive, but just as often it does not. In the meantime, everyone pays the cost of carrying code that does nothing useful today.
YAGNI does not mean pretending the future does not exist. It means refusing to make the present more complicated than it needs to be on the basis of guesses.
Why it matters
YAGNI matters because software is full of seductive maybes. Maybe we will need five payment providers. Maybe we will split this into many small services. Maybe customers will want custom workflows, advanced permissions, plug ins, templates, and bulk import. A head full of maybes can turn one modest product into a warehouse of unproven features.
That has practical consequences. Extra code has to be reviewed, tested, explained, secured, monitored, and changed. Even when nobody uses the feature, the team still needs to understand the machinery around it. The software gets heavier before it gets wiser.
For leaders and product people, YAGNI is valuable because it protects learning speed. It shifts effort away from imagined futures and back towards the next thing the team can actually ship, observe, and improve. In a young product or a changing market, that is often the difference between momentum and drift.
How it works
Where the phrase came from
YAGNI grew out of Extreme Programming, often shortened to XP, in the late 1990s. Martin Fowler traces the phrase to an early conversation between Kent Beck and Chet Hendrickson on the Chrysler C3 project. The slogan stuck because it was memorable, a little cheeky, and annoyingly effective.
It sits alongside another XP line, "Do the simplest thing that could possibly work". Put together, those ideas encourage teams to solve the problem actually on the table, not the larger and more glamorous problem that might turn up later.
Why waiting is often cheaper
The principle looks conservative, but it is really about economics. Building something early creates at least three costs.
First, there is the direct build cost. Someone has to design it, code it, test it, and explain it.
Second, there is the cost of delay. Time spent building a future feature is time not spent delivering the thing users need now. A team can be very busy and still be late to the valuable part.
Third, there is the carrying cost. Every extra branch, class, setting, and interface makes the codebase harder to understand. Even if that future feature is never switched on, it still takes up room in people's heads. Fowler frames this as the cost of carrying extra complexity, and it is one reason YAGNI is about more than just shipping faster.
How YAGNI survives contact with reality
The usual objection is obvious: what if the future really does arrive? What if the thing you skipped turns out to be needed after all?
That can happen. YAGNI is not a promise that waiting is always free. It is a judgement that speculative design usually costs more than it saves, provided the team keeps the code easy to change. This is why YAGNI depends on refactoring, meaning improving the internal structure of code without changing what users see. It also depends on tests, continuous integration, and a culture that treats design as something that evolves rather than something that must be guessed perfectly on day one.
In other words, YAGNI is not simply a restraint principle. It is a bargain. We will not build tomorrow's feature today, and in return we will keep today's code malleable enough to change tomorrow.
What it looks like in practice
A team building an online shop starts with one tax regime instead of a universal rule engine for every country on earth. A company with one application keeps it as one deployable unit instead of breaking it into many small services before the business model is proven. A reporting tool has one export format because that is what customers asked for, not six because "someone will probably want them". A permission model starts with admin and standard user, not a cathedral of nested roles.
YAGNI also applies to code reuse and abstraction. Engineers often see repeated patterns once or twice and are tempted to jump straight to a master framework. Good teams wait for the third or fourth real repetition before they generalise. That way, the shared shape is discovered from experience rather than invented in hope.
This is where YAGNI differs from mere frugality. It is not "do less because less is cheap". It is "do less because reality will teach you what deserves to exist".
What YAGNI is not
YAGNI is not an instruction to build flimsy rubbish. It does not excuse poor naming, weak tests, careless security, or ignoring hard requirements. If your product must meet a legal rule, an accessibility standard, a known traffic level, or a latency target, then that work is not speculative. It is part of the present requirement.
Nor is YAGNI anti design. Teams still design. They just do so in smaller, more reversible moves. Instead of drawing a grand map for every future district in the city, they make one street easy to extend when the next district becomes real.
That is why the Boy Scout Rule belongs nearby. If everyone leaves the code a little clearer each time they touch it, waiting becomes less scary. Without that steady tidying, YAGNI can sound brave on paper and feel reckless in reality.
Examples
A product team is building a booking app for local classes. They know that one day they might handle subscriptions, gift cards, agency logins, and marketplace payouts. Instead of modelling every one of those cases from the start, they build single event bookings and one payment flow. The app launches. Real customers use it. Six weeks later, the team learns that waitlists matter far more than gift cards. YAGNI has protected attention.
An engineering team assumes a successful product will eventually need many small services. Rather than split the system immediately, they build one well organised application with clean module boundaries. A year later, they have real usage patterns and can see which boundaries are stable enough to separate and which ones were just wishful thinking.
A developer is adding file uploads. While working, they imagine that future customers might want uploads from local files, cloud storage, email, mobile camera, and a public programming interface. YAGNI says: support the route users need now, keep the code tidy, and wait until the second route is a fact rather than a fantasy.
Common misunderstandings
A common misunderstanding is that YAGNI means "do the dumbest thing possible". It does not. The principle asks for the simplest thing that meets the current need well, not the flimsiest thing a team can get away with.
Another misunderstanding is that YAGNI forbids all foresight. It does not. Good engineers still notice where change is likely. They simply resist turning that hunch into permanent structure before it has earned its place.
Some people think YAGNI means code should never be reusable. The principle is softer than that. Reuse is welcome when repeated real needs reveal the shape of something shared. It is speculative reuse that causes trouble.
There is also a myth that YAGNI conflicts with design. In healthy teams it usually sharpens design. By stripping away imaginary requirements, it forces the team to understand the real problem more clearly.
Risks and boundaries
YAGNI can be overapplied. A team may hide behind it to avoid difficult but genuine requirements. If security, compliance, accessibility, data retention, or known performance demands are already part of the brief, they are not "later". They are now.
It can also fail when code is hard to change. If a team skips future facing design but also neglects tests, refactoring, and basic structure, it will not feel clever later. It will feel cornered. YAGNI is only safe when the team invests in changeability.
There are also cases where an early decision is genuinely expensive to reverse, especially in widely used public interfaces or infrastructure with long lived contracts. In those cases, a little more foresight may be wise. The line is not "never think ahead". The line is do not make today's code serve tomorrow's guesses unless the cost of waiting is truly higher.
What to do next
If your team keeps building for imaginary futures, begin by making non goals visible. Put in writing what the current release is not trying to do. That sounds basic, but it has a calming effect on a room full of enthusiastic engineers.
When a proposal appears for extra flexibility, ask three questions. What present need does this serve? What complexity does it add right now? What would it really cost to add later if the need becomes real? Those questions turn YAGNI from a slogan into a decision habit.
Protect the practices that make YAGNI safe. Keep tests healthy. Make refactoring normal. Encourage small, reversible design moves. Reward teams for shipping useful changes and for deleting code that only exists for imagined futures.
Most of all, stop equating visible complexity with seriousness. Mature teams are not the ones that prebuild every future. They are the ones that can adapt quickly when the future finally chooses one.
FAQs
What does YAGNI actually stand for?
It stands for "You aren't gonna need it". The phrase says a capability should not be built until there is a real need for it.
Is YAGNI the same as building an MVP?
They are related, but not identical. MVP is about learning from the smallest useful product. YAGNI is a design habit that resists speculative features and abstractions.
Does YAGNI mean we should never plan ahead?
No. It means plans should not automatically become code. You can recognise likely future needs without building all of them today.
What makes YAGNI safe?
A codebase that is easy to change. Tests, refactoring, clear structure, and steady code review are what make delayed decisions practical.
Is YAGNI anti architecture?
No. It is anti speculative architecture. Teams still design, but in smaller steps and with more willingness to revise.
When should we ignore YAGNI?
When the requirement is already real and costly to defer, such as compliance rules, known scale targets, strict performance needs, or long lived public contracts.