you ain’t gonna need it (YAGNI)

You ain’t gonna need it, or YAGNI, is a design principle that says a developer should build a capability only when it’s actually needed, not when someone merely expects to need it later. Also written you aren’t gonna need it, it’s one of the habits that keeps an agile team’s codebase small enough to keep changing. A proposed piece of work falls into one of three cases:

Proposed work splits three ways: outside YAGNI, build now, or presumptive and deferred to avoid four costs.
Two Reasons to Build, One Reason to Wait

The principle comes from Extreme Programming (XP), where Kent Beck kept telling Chet Hendrickson that the capabilities he was anticipating weren’t going to be needed. Ron Jeffries, another XP founder, states the rule directly: “Always implement things when you actually need them, never when you just foresee that you need them.” Martin Fowler calls the thing being avoided a presumptive feature, meaning code for a feature nobody can use yet.

Say a user story asks for a report to be written to a CSV file. A presumptive version of the exporter ships formats and destinations nobody has asked for yet:

Python 
import csv
import json


def export_report(rows, path, fmt="csv", compress=False, upload_to=None):
    if fmt == "json":
        with open(path, "w") as file:
            json.dump(rows, file)
    else:
        with open(path, "w", newline="") as file:
            csv.writer(file).writerows(rows)
    if compress or upload_to:
        raise NotImplementedError("compression and upload land next quarter")

The JSON branch has no caller and no test, and the last two parameters are promises the function can’t keep. The version the story asked for is the whole job:

Python 
import csv


def export_report(rows, path):
    with open(path, "w", newline="") as file:
        csv.writer(file).writerows(rows)

Both versions satisfy the story. The second has no dead branch to maintain and nothing to unpick when the second format turns out to be Parquet rather than JSON.

How It Shows Up in Practice

A Python developer usually meets YAGNI as a review comment, often in shorthand: “YAGNI, drop the backend argument until there’s a second backend.” It surfaces again in planning, when a one-line integration is proposed as a plugin system, or when a class grows an abstract base class for its only subclass.

The principle assumes the team can change its mind cheaply later. That’s why it travels with refactoring, automated tests, and continuous delivery. Without them, nothing keeps the code safe to reshape once the real requirement lands, and deferring a decision turns into a gamble.

At product scale, the same instinct shows up as the minimum viable product, which ships the smallest thing that tests an idea instead of the full roadmap.

The Cost of a Presumptive Feature

Fowler breaks the price of building too early into four parts:

  • Cost of build: The analysis, coding, and testing spent on something nobody has asked for.
  • Cost of delay: That effort pushes back the features users are actually waiting on.
  • Cost of carry: The extra code sits in the way of every later change and makes the software harder to read, modify, and debug.
  • Cost of repair: A feature built from a guess is usually the wrong feature, so it gets reworked or deleted once the real requirement arrives.

The principle is narrower than it first sounds. Fowler is explicit that “Yagni only applies to capabilities built into the software to support a presumptive feature, it does not apply to effort to make the software easier to modify.”

Clean structure, test coverage, and a fast pipeline are what make it safe to say no for now, so they fall outside the principle. Skipping them while still deferring the work is how a team ends up with technical debt instead of flexibility.

Refactoring Python Applications for Simplicity

Tutorial

Refactoring Python Applications for Simplicity

In this step-by-step tutorial, you'll learn how to refactor your Python application to be simpler and more maintainable and have fewer bugs. You'll cover code metrics, refactoring tools, and common anti-patterns.

intermediate best-practices

For additional information on related topics, take a look at the following resources:

Have a question about this? Mentor AI can show you examples, compare related terms, and point you to tutorials.

  • Ask Mentor AI
  • Pick a question and Mentor AI takes it from here.
By Martin Breuss • Updated Oct. 22, 2026
Software Engineering Glossary Share Feedback