YAGNI — You Aren't Gonna Need It — Coding notes

WHAT is YAGNI?

It is the discipline twin of Simplicity and KISS — Keep It Simple. While KISS says "make the thing you build simple," YAGNI says "don't build the thing at all (yet)."

WHY does YAGNI work? (derivation from first principles)

We can reason about it like an expected-value problem. Speculative feature has:

$p$ = probability the feature is ever actually needed as you imagined it.
$C_{\text{build}}$ = cost to build it now.
$C_{\text{carry}}$ = ongoing cost of carrying it (it must be read, tested, maintained, refactored around) even while unused.
$S$ = savings if you build now AND the guess is correct (you avoid building later).
$C_{\text{later}}$ = cost to build it later when truly needed (often cheaper, because you'll then know the real requirement).

Formula Expected value of building speculatively now

Build-now is worth it only if its expected payoff beats "wait": $\underbrace{p\cdot S}_{\text{benefit if guess right}} \;>\; \underbrace{C_{\text{build}} + C_{\text{carry}}}_{\text{paid for sure}}$

Derivation. If you build now you always pay $C_{\text{build}}+C_{\text{carry}}$ . With probability $p$ you save $S$ (you skip the later build); with probability $1-p$ you wasted it. So $E[\text{build now}] = p\,S - (C_{\text{build}} + C_{\text{carry}}).$ Building now beats waiting when $E[\text{build now}] > 0$ , i.e. $p\,S > C_{\text{build}}+C_{\text{carry}}$ .

HOW to apply YAGNI (the workflow)

Trigger check: Is there a concrete, present requirement (a user story, a ticket, a failing acceptance test)? If no → stop.
Forecast-then-Verify: Write down why you think you'll need this. Predict when. Most predictions never come true — keep a log and see.
Build the simplest thing that satisfies the current need only.
Refactor when the second case arrives (see Rule of Three: abstract on the third occurrence, not the first).

Worked example Worked example 1 — the "configurable" database

Story: Save user records to PostgreSQL. Tempting speculative code:

class UserRepo:
    def __init__(self, backend="postgres"):
        self.backend = backend  # "mongo", "mysql", "s3" ... someday!

Why this feels right: "What if we switch databases later? I'll save us a rewrite." YAGNI fix:

class UserRepo:
    def __init__(self, pg_conn):
        self.pg = pg_conn

Why this step? There is no ticket asking for Mongo. $p$ is tiny, and the abstraction layer is read & maintained forever ( $C_{\text{carry}}$ ). If a real switch comes, you'll refactor — and you'll know the real interface needed.

Figure — YAGNI — You Aren't Gonna Need It

Common mistakes (Steel-manned)

Active recall

Recall Quick self-test (cover the answers)

What does the YAGNI inequality say must hold to justify speculative building? → $p\,S > C_{\text{build}}+C_{\text{carry}}$ .
Why does $C_{\text{carry}}$ make speculation expensive? → it is paid every day the unused code lives.
Does YAGNI tell you to skip input validation on a present endpoint? → No, that's a present requirement.
When do you finally add an abstraction? → On the third real occurrence (Rule of Three).

What does YAGNI stand for?

You Aren't Gonna Need It.

YAGNI core rule in one sentence?

Implement functionality only when you actually need it now, never just because you foresee needing it.

Inequality justifying speculative build now?

p·S > C_build + C_carry (expected benefit must exceed certain cost).

Why is C_carry the hidden killer?

Unused speculative code must still be read, tested, maintained and refactored around — a cost paid continuously even though it delivers nothing.

Why is building later often CHEAPER than building speculatively now?

Later you have the real requirement, so you avoid wrong guesses and rework (C_later < C_build for the actually-correct design).

Does YAGNI mean "no architecture / no validation"?

No — it forbids speculative future features, not design or non-functional needs required by the present.

YAGNI vs DRY difference?

DRY removes existing duplication; YAGNI prevents speculative future code. Abstracting too early to be DRY can violate YAGNI.

When should you finally extract an abstraction?

On the third real occurrence — the Rule of Three.

Recall Feynman: explain it to a 12-year-old

Imagine you're packing a small bag for a one-day school trip. A friend says "bring a tent, a stove, and snow boots — just in case we get lost in the mountains!" But you're going to a park for a few hours. Carrying all that heavy stuff every minute is real work, and you'll almost certainly never use it. YAGNI is just: only pack what today's trip needs. If a mountain trip ever happens for real, you'll pack for it then — and you'll know exactly what to bring.

Connections

KISS — Keep It Simple — build the present thing simply; YAGNI says maybe don't build it.
DRY — Don't Repeat Yourself — fight existing duplication, but not prematurely.
Rule of Three — the timing rule YAGNI hands off to for abstraction.
Premature Optimization — same disease (speculation), performance flavor.
Extreme Programming — the methodology YAGNI comes from.
Technical Debt — speculative code is pre-paid debt with no asset.

Concept Map

Hinglish (regional understanding)

Intuition Hinglish mein samjho

YAGNI ka matlab simple hai: "You Aren't Gonna Need It" — yaani jab tak abhi, is waqt, kisi feature ki real zaroorat na ho, tab tak usse mat banao. Hum log coding karte time aksar sochte hain "abhi config option add kar deta hoon, kal kaam aayega", ya "interface generic bana deta hoon, future mein Mongo, SQL, S3 sab support karna padega". Lekin sach yeh hai ki future ka tumhara guess zyada tar galat nikalta hai — requirement badal jaati hai.

Ise expected value se samjho: speculative code banane ka benefit tabhi milta hai jab guess sahi ho (probability p, savings S), par cost toh hamesha deni padti hai — banane ki cost plus carry cost (har din us code ko padhna, test karna, maintain karna). Formula banta hai: build karo tabhi jab $p \cdot S > C_{build} + C_{carry}$ . Real life mein p chhota hota hai aur carry cost daily lagti hai, isliye yeh inequality usually fail karti hai — matlab abhi mat banao, defer karo.

Ek important confusion clear karo: YAGNI ka matlab "kuch bhi proper mat banao" NAHI hai. Input validation, security, error handling jo abhi ki requirement hain — woh toh banane hi hain. YAGNI sirf speculative future features ko rokta hai, na ki present ki genuine needs ko. Aur jab teesri baar wahi cheez sach mein repeat ho (Rule of Three), tab abstraction banao — pehli baar mein nahi.

Bottom line: ek guess koi ticket nahi hai. Jab tak concrete present requirement na ho, code mat likho. Isse codebase chhota, simple, easy-to-change rehta hai — aur jab real zaroorat aati hai to tum behtar, sahi design banate ho.

YAGNI — You Aren't Gonna Need It

WHAT is YAGNI?

WHY does YAGNI work? (derivation from first principles)

HOW to apply YAGNI (the workflow)

Common mistakes (Steel-manned)

Active recall

Connections

Concept Map

Hinglish (regional understanding)

Go deeper — visual, from zero

Test yourself — Design Principles

Connections