A couple buys a seven-seater car "because we might have a big family someday". For the next five years they pay more for fuel, struggle to park it, and drive around with five empty seats. When the family finally grows, they need a car with a child seat and a bigger boot, which the seven-seater does not have anyway. The guess cost money every day and still turned out wrong.

Software teams make the same bet all the time. We add a plugin system for one plugin, a factory for one class, or a settings screen that nobody opens. The principle that warns against this is YAGNI, short for You Aren't Gonna Need It.

"Always implement things when you actually need them, never when you just foresee that you need them." (Ron Jeffries, one of the founders of Extreme Programming)

Real-world analogy: a good tailor stitches the shirt for the measurements you have today. They do not add extra cloth for every way your size might change in ten years. If you need an alteration later, they alter it then, with the right measurements.

1. What Is the YAGNI Principle?

YAGNI says: build for the requirement you have, not the one you imagine. If a feature, a parameter or a layer of abstraction is not needed for what you are delivering now, leave it out. When the need really arrives, you will know much more about it and can build the right thing.

The idea comes from Extreme Programming, one of the early Agile methods. Its starting point was that requirements change constantly, so time spent building for predicted futures is mostly wasted. Deliver the simplest thing that works, get feedback, and grow it.

YAGNI is not permission to write sloppy code. Clean names, small classes, tests and proper error handling are all part of building today's feature well. What YAGNI removes is speculative work: features, options and abstractions that no current requirement asks for.

2. Why Building for the Future Costs More Than It Seems

A feature built early is not a one-time cost. You pay for it every week it exists, long before anyone uses it.

  • You pay to build and test it now, which delays what users are actually waiting for.
  • You pay to maintain it. Every refactor, upgrade and code review has to carry the extra code along.
  • It makes the real code harder to read. New team members cannot tell which parts are used and which are dead.
  • The guess is often wrong. When the real requirement arrives it rarely matches what was imagined, so the early work gets rewritten or deleted.

3. A YAGNI Violation: The Over-Built Attendance App

A college asks for a simple feature: teachers mark each student present or absent every day, and the app shows each student's attendance percentage. The developer, thinking ahead, also prepares for biometric scanners, face recognition cameras, PDF and Excel export, and a settings object with options like time zone and grace minutes.

Output

Asha: 75%
Ravi: 50%
Meena: 100%
Never used: BiometricSource, FaceScanSource, PdfExporter, ExcelExporter, 3 settings

The percentages are right, but look at what it took. Only ManualSource, the engine and the text exporter do real work. The scanner sources return dummy values because nobody has the hardware, the PDF and Excel exporters return "TODO", and none of the settings is ever changed. Every one of those classes still has to compile, be reviewed and be understood by the next developer.

4. The YAGNI Version

Here is the same requirement built for today. One class, AttendanceRegister, stores each student's daily marks and calculates the percentage.

Output

Asha: 75%
Ravi: 50%
Meena: 100%

Same output, a fraction of the code. There is nothing to configure and nothing that pretends to work. Notice that the class is still well designed: the data is private, the methods have clear names, and the percentage logic lives in one place. YAGNI did not make the code worse. It only removed what nobody asked for.

5. Speculative Parameters and Flags

YAGNI is not only about big frameworks. It also applies to small things like method parameters. Here a receipt formatter was written to support dollars, euros, decimal places and an option to hide the currency symbol. Every caller in the college fee app passes the same values, so the method is really just "add Rs in front of the number".

Output

Hostel fee: Rs 45000  (same output)
Mess fee: Rs 18000  (same output)
Bus pass: Rs 6500  (same output)

Both methods produce identical receipts, but the first one forces every caller to pass four arguments and every reader to wonder whether the other currencies are used somewhere. Unused parameters and boolean flags are a quiet form of speculative design. If you find that every call site passes the same values, remove the options.

6. Add It When the Need Is Real

A month after the attendance app goes live, the principal asks for something new: a list of students below 75% so the college can send warning letters. This is a real requirement with a real user, so now is the time to build it.

Output

Asha: 80%
Ravi: 40%
Meena: 100%
Kiran: 60%
Below 75%: Ravi, Kiran

Because the register was kept small, the new feature is one method, studentsBelow(), and nothing else in the class changed. Compare that with the over-built version: the new feature would have to be threaded through the engine, the sources and possibly every exporter.

This is the real promise of YAGNI. Simple code that does today's job well is the easiest code to extend tomorrow.

7. When to Think Ahead Anyway

YAGNI does not mean you should never think about the future. Some decisions are expensive to change later, and it is fair to spend a little effort on them early:

  • Data formats and database schemas that will hold real user data, because migrating them later is costly.
  • Public APIs used by other teams or apps, where a change can break clients you do not control.
  • Security and privacy, such as storing passwords hashed from day one.
  • Known, committed requirements already scheduled for the next sprint, as opposed to "maybe one day".

For everything else, keep the code clean and small, write a note in the backlog, and move on.

8. YAGNI and Other Principles

YAGNI and KISS work as a pair: KISS keeps what you build simple, and YAGNI stops you from building what you do not need. YAGNI also tempers DRY: do not create a shared helper for a second use case that does not exist yet. Even the Open/Closed Principle is best applied when you know which parts actually vary, which you usually learn only after the second or third real change request.

9. Common Signs You Are Breaking YAGNI

  • Interfaces or abstract classes with exactly one implementation "for future use".
  • Methods that throw "not implemented" or return placeholder values.
  • Parameters and boolean flags that every caller sets to the same value.
  • Settings and configuration options that nobody has ever changed.
  • Code comments like "in case we need it later" or "for v2".
  • Large commented-out blocks kept "just in case". Version control already remembers them.

Summary

  • YAGNI means building only what today's requirement needs, and adding features when they are actually requested.
  • Speculative features cost time to build, slow down every future change, and are often wrong when the real need arrives.
  • YAGNI is not an excuse for poor code. Today's feature should still be clean, tested and well named.
  • Watch for small violations too: unused parameters, flags and settings.
  • Do think ahead for things that are expensive to change, such as data formats, public APIs and security.

The future will arrive with its own requirements. The best preparation for it is code that is small, clear and easy to change.