YAGNI — You Aren't Gonna Need It: Worked examples

Recall the single tool we use. When you consider writing a piece of speculative code, four plain-English quantities exist:

Why an inequality and not a yes/no rule? Because "should I build this?" is really "is the expected gain bigger than the certain loss?" — a comparison of two numbers. An inequality is exactly the tool that answers "which side is bigger?". See the balance-scale picture:

Figure — YAGNI — You Aren't Gonna Need It

The scenario matrix

Every real coding decision falls into one of these cells. Our job below: hit every cell with a worked example.

Cell	Regime of the inequality	Real-world flavour
A	$p$ tiny, $C_{carry} > 0$ → LHS $≪$ RHS	classic speculative "config layer"
B	$p$ high, but $S$ small (cheap to add later) → still fails	"obvious" future feature that's cheap to add later
C	$p \approx 1$ now (present requirement) → not speculative at all	validation / auth / security
D	$p$ genuinely high and $S$ huge & irreversible later → LHS wins	the rare build-now exception
E	Degenerate: $C_{carry} = 0$ (truly free hook)	the "it's basically free" claim
F	Limiting case: $p \to 1$ as you wait (deferral raises certainty)	forecast-then-verify timing
G	DRY-vs-YAGNI collision (duplication count $= 2$ )	abstract now or wait for third?
H	Exam twist: numbers given, decide + justify	plug-in computation

Worked examples

Worked example Example 1 — Cell A: the "configurable database" (p tiny)

Statement. A ticket says "save users to PostgreSQL." You want to add a backend="postgres" switch for future Mongo/MySQL. Estimate $p = 0.1$ , $S = 8$ hours saved, $C_{build} = 3$ h, $C_{carry} = 6$ h over the code's life. Build now?

Forecast: Guess the sign of $p \cdot S - (C_{build} + C_{carry})$ before computing.

Compute LHS $= p \cdot S = 0.1 \times 8 = 0.8$ h. Why this step? LHS is the expected benefit — the payoff weighted by how likely it is.
Compute RHS $= C_{build} + C_{carry} = 3 + 6 = 9$ h. Why this step? This is paid with certainty (probability $1$ ), so no weighting.
Compare: $0.8 < 9$ . Inequality fails → do not build the abstraction. Why this step? The rule says build only when LHS beats RHS.

Verify: Expected net $= 0.8 - 9 = - 8.2$ h. Negative → you lose ~8 hours on average. Ship the plain UserRepo(pg_conn). Matches Simplicity.

Worked example Example 3 — Cell C: present requirement (NOT speculative)

Statement. A public endpoint takes untrusted input. Should you add input validation & auth "even though YAGNI"?

Forecast: which quantity is different here?

Identify $p$ . The requirement (security/correctness) exists today, so $p = 1$ now, not a future guess. Why? YAGNI only fires on speculative future items. A present need has $p = 1$ by definition.
Apply inequality with $p = 1$ : $1 \cdot S > C_{build} + C_{carry}$ where $S$ = value of not being hacked (enormous, effectively $\infty$ ). Why? Any positive certain cost is dwarfed by preventing a breach.
Conclusion: build it, well, now. YAGNI is silent here. Why? Misreading this cell is the most dangerous mistake (parent note, Example 3).

Verify: With $S \to \infty$ , LHS $\to \infty >$ any finite RHS. Always build. ✔

Worked example Example 4 — Cell D: the rare build-now exception (irreversible, high p, huge S)

Statement. You're choosing a database's primary-key type. Making IDs UUID vs int now is a 1-h decision; migrating a live billion-row table later is catastrophic. $p = 0.8$ you'll need global uniqueness, $S = 200$ h saved (avoided migration + downtime), $C_{build} = 1$ h, $C_{carry} = 1$ h.

Forecast: does anything ever justify building now?

LHS $= 0.8 \times 200 = 160$ h. Why? When "later" is astronomically expensive (irreversible schema), $S$ is huge.
RHS $= 1 + 1 = 2$ h.
Compare: $160 > 2$ → build now. YAGNI agrees. Why? YAGNI is not dogma; it's this inequality. When LHS genuinely wins, you build.

Verify: Net $= + 158$ h. This is the boundary case people forget: YAGNI permits foresight when the math supports it (high $p$ , huge irreversible $S$ ). Compare Premature Optimization — same logic, perf flavour.

Worked example Example 5 — Cell E: the "it's basically free" claim (C_carry = 0?)

Statement. "Adding an empty on_event extension hook is free — 5 minutes." Test the claim by setting $C_{build} = 0.08$ h (5 min), $S = 4$ h, $p = 0.15$ . Is $C_{carry}$ really $0$ ?

Forecast: is any hook truly free forever?

Test $C_{carry} = 0$ : LHS $= 0.15 \times 4 = 0.6$ ; RHS $= 0.08 + 0 = 0.08$ ; $0.6 > 0.08$ → would say build. Why? If carry were truly zero, cheap speculation could pass.
Reject the premise. Every reader must understand the hook, every test must cover it, every refactor must preserve it → realistic lifetime $C_{carry} = 2$ h minimum (summed over its whole life). Why? $C_{carry} = 0$ is a degenerate, impossible input for shipped code.
Recompute: RHS $= 0.08 + 2 = 2.08$ ; $0.6 < 2.08$ → don't build. Why? The lie is in the hidden $C_{carry}$ , not the 5 minutes.

Verify: Net with real carry $= 0.6 - 2.08 = - 1.48$ h. The "free hook" costs you. This defeats the first mistake in the parent note. Links to Technical Debt — a hook is pre-paid debt.

The figure below turns this example into a picture: the orange bar is the claimed 5-minute cost, the tall violet bar is the ignored lifetime $C_{carry}$ , and the magenta dashed line is the expected benefit $p \cdot S = 0.6$ h. Notice how the benefit line clears the "free" bar on the left but is buried under the real cost on the right — that visual gap is why the hook isn't free.

Worked example Example 6 — Cell F: forecast-then-verify (p rises while you WAIT)

Statement. Today a feature has guess-probability $p_{0} = 0.2$ , with speculative savings $S = 5$ h, build cost $C_{build} = 2$ h, and lifetime carry $C_{carry} = 3$ h. If you instead wait until a real ticket appears, the feature only gets built in the $20%$ of futures where it's truly needed, and building it then costs $C_{later} = 2$ h (cheaper — real spec in hand). Show waiting dominates.

Forecast: how does time change the numbers?

Now: build-now expected value $= p_{0} S - (C_{build} + C_{carry}) = 0.2 \times 5 - (2 + 3) = 1.0 - 5 = - 4$ h. Why? Guessing early means low $p_{0}$ and you pay the full certain cost $C_{build} + C_{carry} = 5$ h regardless.
Wait: you pay $0$ until a ticket exists. If it never comes ( $80%$ ), you spent nothing. If it comes ( $20%$ ), you build then for $C_{later} = 2$ h. Why? Deferral converts an early guess into a late certainty — you only pay in the futures that actually occur.
Expected cost of waiting $= 0.2 \times C_{later} = 0.2 \times 2 = 0.4$ h, versus the build-now certain cost of $C_{build} + C_{carry} = 5$ h. Why? $0.4 ≪ 5$ : waiting is ~12× cheaper.

Verify: $E [wait] = 0.4$ h $<$ build-now cost $= 5$ h. Difference $= 4.6$ h saved by deferring. This is why the workflow says log your forecast and verify it later.

Worked example Example 7 — Cell G: DRY-vs-YAGNI collision (duplication count = 2)

Statement. You see the same 3 lines copied in two places. DRY screams "abstract!" YAGNI/Rule of Three says "wait for the third." Occurrences $n = 2$ . Model: abstracting costs $C_{build} = 2$ h; if a third case comes it must fit your abstraction (probability the abstraction is right $= 0.5$ with only 2 samples). Wrong abstraction costs $C_{rework} = 4$ h.

Forecast: abstract at $n = 2$ or wait for $n = 3$ ?

Cost of abstracting at $n = 2$ : $C_{build} + (1 - 0.5) C_{rework} = 2 + 0.5 \times 4 = 4$ h. Why? With only 2 examples you often guess the shared shape wrong → rework.
Cost of waiting for $n = 3$ : duplicate the third line ( $\approx 0.2$ h) then abstract from three real samples ( $C_{build} = 2$ h, now right): $= 2.2$ h. Why? Three data points reveal the true common interface, killing rework.
Compare: $2.2 < 4$ → wait. Abstracting on the 2nd copy violates YAGNI. Why? This is the exact DRY — Don't Repeat Yourself vs YAGNI resolution from the parent.

Verify: Waiting saves $4 - 2.2 = 1.8$ h. Rule of Three wins. ✔

Worked example Example 8 — Cell H: exam twist (given numbers, decide + justify)

Statement (exam-style). A candidate feature: $p = 0.35$ , $S = 20$ h, $C_{build} = 5$ h, $C_{carry} = 4$ h. (a) Should you build now? (b) What is the break-even probability $p_{⋆}$ at which you'd be indifferent?

Forecast: guess whether $p = 0.35$ clears the bar.

(a) LHS $= 0.35 \times 20 = 7$ h; RHS $= 5 + 4 = 9$ h; $7 < 9$ → don't build. Why? Direct application of the inequality.
(b) Break-even: set $p_{⋆} S = C_{build} + C_{carry}$ → $p_{⋆} = \frac{C _{build} + C _{carry}}{S} = \frac{9}{20} = 0.45$ . Why? Solving the inequality as an equality gives the threshold probability. You'd need $p \geq 0.45$ to justify building; you only have $0.35$ .
Interpret: your guess must be $\geq 45%$ likely; a $35%$ hunch isn't enough. Why? Turns a vibe into a number — that's the exam's point.

Verify: $p = 0.35 < p_{⋆} = 0.45$ , and $7 < 9$ , consistent. Net now $= 7 - 9 = - 2$ h.

Active recall

Recall Cover the answers

Which cell is a present requirement (validation/auth)? ::: Cell C — $p = 1$ now, YAGNI is silent, build it well. In Example 5 what was the lie? ::: That $C_{carry} = 0$ ; real lifetime carry (~2 h) flips the decision to "don't build." Break-even probability formula? ::: $p_{⋆} = (C_{build} + C_{carry}) / S$ . Difference between $S$ and $C_{later}$ ? ::: $S$ = savings you collect for guessing right today; $C_{later}$ = the bill you actually pay if you build it later. Why does a high $p$ still not justify Example 2? ::: Because $S$ (savings) is tiny — building later is cheap, so LHS stays below RHS. When does YAGNI itself say "build now" (Cell D)? ::: When $p$ is high AND $S$ is huge/irreversible, so $p \cdot S$ beats the certain cost.

Connections

YAGNI — You Aren't Gonna Need It — the parent rule these examples exercise.
Rule of Three — the timing rule behind Cell G.
DRY — Don't Repeat Yourself — the tension resolved in Example 7.
KISS — Keep It Simple & Simplicity — what you build instead.
Premature Optimization — same inequality, performance flavour.
Technical Debt — the "free hook" of Example 5 is pre-paid debt.
Extreme Programming — where YAGNI originates.