Walter Nascimento

Posted on Feb 12

YAGNI: The Principle That Protects You From Building the Future Too Early

#programming #softwaredevelopment #softwareengineering #cleancode

Most developers don’t struggle with laziness.

They struggle with imagination.

We imagine scale.
We imagine new features.
We imagine flexibility.
We imagine “what if”.

And that’s exactly where YAGNI comes in.

What YAGNI Really Means

YAGNI stands for:

You Aren’t Gonna Need It

The rule is brutally simple:

If you don’t need it now, don’t build it now.

Not “just in case”.
Not because it looks architecturally elegant.

Where YAGNI Came From

YAGNI was introduced as part of Extreme Programming (XP) in the late 1990s by Kent Beck.

Extreme Programming challenged traditional software thinking:

Deliver fast
Iterate often
Refactor constantly
Avoid speculative design

Instead of predicting every future scenario, XP embraced incremental evolution.

YAGNI became one of its core disciplines.

Not because future-proofing is bad.

But because speculative complexity is expensive.

The Real Enemy: Speculative Engineering

Most violations of YAGNI look intelligent.

They look like:

Adding abstraction layers “for scalability”
Creating interfaces for implementations that don’t exist
Building configuration systems before variation is real
Designing for multi-tenancy with a single client

The reasoning is always the same:

“We might need this.”

But most of the time?

You won’t.

And you just increased:

Cognitive load
Maintenance cost
Bug surface area
Onboarding friction

All for a future that never arrived.

A Simple Example

Let’s say you only use Stripe.

❌ Overengineered version

class PaymentStrategy:
    def execute(self, amount):
        pass


class StripeStrategy(PaymentStrategy):
    def execute(self, amount):
        return f"Processing {amount} with Stripe"


class PayPalStrategy(PaymentStrategy):
    def execute(self, amount):
        return f"Processing {amount} with PayPal"


class PaymentProcessor:
    def __init__(self, strategy: PaymentStrategy):
        self.strategy = strategy

    def process(self, amount):
        return self.strategy.execute(amount)

Looks clean.
Looks extensible.
Looks “architectural”.

But there is no PayPal.
There is no roadmap.
There is no second gateway.

You built optionality that does not exist.

✅ YAGNI version

class PaymentProcessor:
    def process(self, amount):
        return f"Processing {amount} with Stripe"

Simple.
Clear.
Honest.

If PayPal becomes real?

You refactor.

And refactoring is cheaper than maintaining imaginary flexibility.

“But What About Scaling?”

This is where people panic.

They think YAGNI means:

Ignore design
Ignore growth
Ignore architecture

It doesn’t.

YAGNI doesn’t reject foresight.
It rejects speculation without evidence.

There’s a famous quote by Donald Knuth:

“Premature optimization is the root of all evil.”

YAGNI applies the same logic to architecture.

Premature abstraction is just optimization’s cousin.

YAGNI Is About Timing

Engineering is not about building everything correctly on day one.

It’s about:

Building what’s necessary
Validating assumptions
Refactoring when reality demands change

Not when imagination suggests it might.

The best engineers don’t design for every possible future.

They design for change.

That’s different.

When YAGNI Does NOT Apply

YAGNI is powerful.
But not absolute.

You should not apply YAGNI when:

Requirements are contractual and confirmed
Multiple implementations are guaranteed
Public APIs must remain stable
The cost of change later is extremely high

YAGNI fights uncertainty-driven complexity.

It does not fight clarity-driven design.

The Psychological Side of YAGNI

YAGNI is hard because it challenges ego.

Developers often want to:

Prove architectural depth
Demonstrate pattern knowledge
Show foresight
Avoid looking “unprepared”

But mature engineering is not about showing how much you know.

It’s about delivering the simplest correct solution.

Restraint is a skill.

And YAGNI is discipline in action.

The Question That Changes Everything

Before adding:

A new abstraction
A new pattern
A new configuration layer
A new generic system

Ask yourself:

Is this solving a real, current problem?

If not…

You probably aren’t gonna need it.

Final Thought

Software evolves.

Your system will change.
Requirements will shift.
Users will surprise you.

Trying to predict everything is not wisdom.

It’s fear disguised as architecture.

YAGNI reminds us:

Build for now.
Refactor when needed.
Trust evolution.
Respect simplicity.

And most importantly:

Don’t sacrifice today’s clarity for tomorrow’s imagination.

Thanks for reading!

If you have any questions, complaints or tips, you can leave them here in the comments. I will be happy to answer!
😊😊 See you! 😊😊

Support Me

Youtube - WalterNascimentoBarroso
Github - WalterNascimentoBarroso
Codepen - WalterNascimentoBarroso

DEV Community