YAGNI: You Aren't Gonna Need It

Don't add functionality until there's a real, present use case for it.

What Is YAGNI?

YAGNI stands for "You Aren't Gonna Need It." It comes from Extreme Programming (XP) and is a core idea in agile development. The principle says developers should implement things only when they are actually needed, not when they merely foresee needing them.

It's easy to think, "We might need this later, so let's build it now." YAGNI pushes back on that habit.

Why Speculative Features Are a Problem

A Simple Example

❌ Violating YAGNI

Requirement: "Save a user's name to a file."

class DataStorage:
    def __init__(self, storage_type="file"):
        self.storage_type = storage_type

    def save(self, data):
        if self.storage_type == "file":
            self._save_to_file(data)
        elif self.storage_type == "database":
            self._save_to_database(data)   # Nobody asked for this
        elif self.storage_type == "cloud":
            self._save_to_cloud(data)      # Or this

    def _save_to_file(self, data): ...
    def _save_to_database(self, data): ...
    def _save_to_cloud(self, data): ...

✅ Following YAGNI

def save_user_name(name, path="user.txt"):
    with open(path, "w") as f:
        f.write(name)

If a database is required later, you can refactor then, with real requirements in hand.

When Should You Add Something?

Ask yourself these questions before building:

1. Is there a real user story or requirement today?
2. Is someone actually blocked without this?
3. Would adding it later be dramatically more expensive? (Usually it isn't.)

If the answers are no, no, and no, don't build it yet.

Common YAGNI Violations

• Adding configuration options nobody has asked for
• Creating abstract base classes with a single implementation
• Building plugin systems for an app with one use case
• Adding database columns "just in case"
• Supporting multiple languages or currencies before you have international users
• Over-engineering APIs with parameters that are never used

What YAGNI Is Not

YAGNI is often misunderstood. It does not mean:

• ❌ Writing sloppy or unstructured code
• ❌ Ignoring good design and architecture
• ❌ Skipping tests, security, or error handling
• ❌ Refusing to plan at all

The principle applies to features and speculative generality, not to code quality. In fact, YAGNI works best alongside:

• Automated tests, which make later changes safe
• Refactoring, so you can adapt when needs appear
• Continuous integration, for fast feedback
• Simple design (see also: KISS)

YAGNI vs. Related Principles

Caveat: When Anticipating the Future Is Reasonable

There are exceptions where planning ahead makes sense:

• Public APIs or database schemas that are very hard to change later
• Security-critical foundations, such as authentication design
• Regulatory or contractual requirements that are known and certain

The key word is known. If the need is a certainty rather than a guess, it's a real requirement, not speculation.

Key Takeaways

• Build for today's requirements, not imagined future ones.
• Every line of code has a cost: writing, testing, and maintaining it.
• Simple code is easier to change when real needs emerge.
• Combine YAGNI with tests and refactoring so you can evolve safely.
• Delaying a decision until you have more information is often the smartest choice.

"Always implement things when you actually need them, never when you just foresee that you need them."
— Ron Jeffries, co-founder of Extreme Programming

Reference:

• https://martinfowler.com/bliki/Yagni.html