YAGNI — You Aren't Gonna Need It: Exercises — Coding deep dive

Parent: YAGNI — You Aren't Gonna Need It. This page is a graded workout. Every problem has a fully worked solution hidden in a collapsible callout — try first, then reveal.

Before we start, one small piece of math machinery we lean on repeatedly. The parent note gave you the build-now inequality:

Formula The decision rule (memorize this)

Building a speculative feature now beats waiting only if $expected saving if your guess is right p \cdot S > cost you pay for certain C_{build} + C_{carry}$ where:

$p$ = probability (a number between 0 and 1) that the feature is ever really needed as you imagined it. $p = 0$ means "never happens"; $p = 1$ means "certain".
$S$ = money/time saved if the guess turns out right (you skipped building it later).
$C_{build}$ = cost to build it now.
$C_{carry}$ = the ongoing cost of carrying unused code — reading it, testing it, refactoring around it — paid every day it lives.

Read $p \cdot S$ as "multiply the payoff by how likely it is". That is just the expected value: a fair way to weigh an uncertain reward. We use multiplication (not addition) because a big reward that almost never happens should count less, and multiplying by a small $p$ shrinks it.

Everything below is either applying this rule, or applying the workflow from the parent (trigger check → build simplest → refactor on the Rule of Three).

Figure — YAGNI — You Aren't Gonna Need It

The figure above is our mental picture for the whole page. The horizontal amber dashed line is the certain cost $C_{build} + C_{carry}$ — here fixed at $18$ hours; it does not move because you pay it no matter what. The straight cyan line is the expected payoff $p \cdot S$ (with $S = 40$ hours): it starts at $0$ when $p = 0$ and climbs as your guess becomes more likely. They cross at the white dot, the break-even probability $p^{⋆} = (C_{build} + C_{carry}) / S = 0.45$ . Read the axes literally: the horizontal axis is $p$ , the vertical axis is value in hours. The shaded region on the left is where $p \cdot S$ sits below the amber line — "don't build". Almost all real features live in that shaded region because their $p$ is small.

Level 1 — Recognition

L1-Q1

Which of these is the correct expansion of the acronym YAGNI? (a) You Always Get New Ideas (b) You Aren't Gonna Need It (c) Yield A General Non-Interface

Recall Solution

(b) You Aren't Gonna Need It. It is a principle from Extreme Programming: don't add functionality until it is actually needed now.

L1-Q2

Classify each item as SPECULATIVE (YAGNI says defer) or PRESENT NEED (build it well now):

A backend="postgres" parameter with comments listing "mongo", "s3" for "someday".
Input validation on a public API endpoint receiving untrusted data.
A generic send(template, locale, channel, retries, priority, schedule) when the only ticket is "send a welcome email".
Authentication on an admin-only route.

Recall Solution

Speculative — no ticket asks for Mongo/S3. Defer.
Present need — untrusted input is a current security/correctness requirement. Build it.
Speculative — only one channel is needed today; the extra parameters are untested surface area.
Present need — admin routes require auth now to be correct.

Rule of thumb: YAGNI targets speculative future features, never non-functional requirements of the present.

Level 2 — Application

L2-Q1 (plug into the inequality)

A speculative "multi-currency" feature has $p = 0.2$ , $S = 40$ hours, $C_{build} = 12$ hours, $C_{carry} = 6$ hours. Should you build it now?

Recall Solution

Compute both sides.

Expected saving: $p \cdot S = 0.2 \times 40 = 8$ hours.
Certain cost: $C_{build} + C_{carry} = 12 + 6 = 18$ hours.

Is $8 > 18$ ? No. The inequality fails → do not build now. You would pay 18 hours for certain to chase an 8-hour expected reward.

L2-Q2 (find the break-even probability)

Keep $S = 40$ , $C_{build} = 12$ , $C_{carry} = 6$ . What is the smallest $p$ (call it $p^{⋆}$ ) that would just justify building now?

Recall Solution

Set the two sides equal and solve for $p$ : $p^{⋆} \cdot S = C_{build} + C_{carry} \Rightarrow p^{⋆} = \frac{C _{build} + C _{carry}}{S} = \frac{18}{40} = 0.45.$ You'd need to be at least 45% sure the guess is right just to break even. Since real speculative $p$ is usually far below that, YAGNI wins.

L2-Q3 (apply the workflow, not the algebra)

Ticket: "Save user records to PostgreSQL." A teammate writes:

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

Rewrite it the YAGNI way and justify in one sentence.

Recall Solution

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

Justification: No ticket asks for another database, so the backend abstraction has tiny $p$ yet real $C_{carry}$ (read/tested/maintained forever); if a real switch ever comes you refactor then, informed by the actual interface. This mirrors KISS — Keep It Simple: build the present thing, simply.

Level 3 — Analysis

L3-Q1 (why "later" is often cheaper)

The parent claims $C_{later}$ (build it when truly needed) is often less than $C_{build}$ (build it speculatively now). Give the mechanism, then decide: with $p = 0.3$ , $S = 30$ , $C_{build} = 15$ , $C_{carry} = 4$ , and if you wait you'd pay $C_{later} = 10$ only in the $p$ world — which path is better?

Recall Solution

Mechanism: building later, you have the real requirement in hand, so you avoid guessing the wrong interface and the rework that follows. Guessing now risks building the wrong shape → wasted build + a rebuild.

Expected cost of "build now". You always pay $C_{build} + C_{carry} = 15 + 4 = 19$ for certain. Then, with probability $p$ , that spend pays off and saves you $S$ ; with probability $1 - p$ it saves nothing. The expected saving is therefore $p \cdot S + (1 - p) \cdot 0 = p S$ . Why do we simply subtract $p S$ from the certain 19? Because expectation is linear: the expected value of (certain cost minus an uncertain saving) equals (the certain cost) minus (the expected saving) — the two pieces can be averaged separately and combined. So $E_{now} = (C_{build} + C_{carry}) - p S = 19 - 0.3 \times 30 = 19 - 9 = 10.$ Expected cost of "wait". You pay nothing up front, and only in the $p$ world do you pay $C_{later}$ — again by linearity the expected cost is $p \cdot C_{later} + (1 - p) \cdot 0$ : $E_{wait} = p C_{later} = 0.3 \times 10 = 3.$ $E_{wait} = 3 < E_{now} = 10$ → waiting wins by 7 expected hours.

L3-Q2 (the "free hook" fallacy)

A hook takes only 5 minutes to write ( $C_{build} = 5$ min). Over a year, 20 people read the codebase, each losing 2 minutes understanding the unused hook, and 3 refactors each spend 15 minutes preserving it. If $p = 0.1$ and $S = 120$ minutes, was the hook worth it?

Recall Solution

The trap is counting only $C_{build}$ . Compute the hidden carry cost:

reading: $20 \times 2 = 40$ min
refactors: $3 \times 15 = 45$ min
$C_{carry} = 40 + 45 = 85$ min.

Certain cost $= C_{build} + C_{carry} = 5 + 85 = 90$ min. Expected saving $= p S = 0.1 \times 120 = 12$ min. Is $12 > 90$ ? No — the "5-minute" hook actually costs 90 minutes for a 12-minute expected reward. Not worth it.

Lesson: $C_{carry}$ , not $C_{build}$ , is the real price of speculation.

Level 4 — Synthesis

L4-Q1 (YAGNI vs DRY vs Rule of Three)

You spot two functions with the same 6 lines of code. A colleague immediately extracts a shared helper "to be DRY". Is this correct under YAGNI? At what point should you extract?

Recall Solution

Not yet. DRY — Don't Repeat Yourself removes existing duplication, but abstracting on the first repeat is speculative: you're guessing the two cases will stay identical and that a third will come. That guess (small $p$ , real $C_{carry}$ ) is a YAGNI violation.

The correct timing is the Rule of Three: extract on the third real occurrence, when you have enough real examples to see the true shared shape. Two data points can't tell you which parts are genuinely common vs coincidentally alike.

Summary: DRY tells you what (remove duplication), YAGNI/Rule-of-Three tells you when (on the third real case).

L4-Q2 (design the forecast-then-verify log)

Design a tiny "prediction ledger" that turns YAGNI from opinion into evidence. What columns, and how does it feed back into the inequality?

Recall Solution

Columns: feature, predicted_need_date, date_logged, actually_needed? (Y/N), outcome_date.

Loop:

Every time you want to build speculatively, log the prediction instead of coding it.
Periodically review: count how many predictions came true.
That hit-rate is your empirical $p$ — replace gut feeling with data in $p \cdot S > C_{build} + C_{carry}$ .

Most teams discover their real $p$ is tiny, which quantifies why YAGNI wins and links it to avoiding Technical Debt (speculative code is pre-paid debt with no asset) and Premature Optimization (the same speculation disease, performance-flavored).

Level 5 — Mastery

L5-Q1 (general condition + edge cases)

Starting from $p S > C_{build} + C_{carry}$ , derive the general break-even probability $p^{⋆}$ , and interpret all edge cases: $S = 0$ , $C_{carry} = 0$ , $p^{⋆} > 1$ , and $p^{⋆} \leq 0$ .

Recall Solution

Domain assumption first. Savings cannot be negative — you can never lose value by having correctly guessed a need — so $S \geq 0$ . We split on whether $S$ is zero or strictly positive, because we are only allowed to divide by $S$ when $S > 0$ (dividing by zero is undefined).

Derivation (case $S > 0$ ). Divide both sides by $S$ . Since $S > 0$ , the direction of $>$ is preserved: $p > \frac{C _{build} + C _{carry}}{S} = p^{⋆} .$ Edge cases:

$S = 0$ (no saving even if right): we may not divide by $S$ ; go back to the original rule, which becomes $0 > C_{build} + C_{carry}$ , impossible for nonnegative costs → never build.
$C_{carry} = 0$ (magically free to keep): $p^{⋆} = C_{build} / S$ . Still need $p$ above that; carry-free code lowers the bar but doesn't remove it.
$p^{⋆} > 1$ : the threshold exceeds certainty, so even a guaranteed need ( $p = 1$ ) wouldn't justify it → never build. Happens when $C_{build} + C_{carry} > S$ .
$p^{⋆} \leq 0$ : only if costs are $\leq 0$ (a feature that pays you to build). Then always build — but this never happens in practice; costs are positive.

This is the complete map: for realistic positive costs, $0 < p^{⋆} \leq 1$ , and you build only if your evidence-based $p$ clears it.

L5-Q2 (full scenario, end to end)

You have a live app. Ticket: "Add CSV export of the current report." You're tempted to build a generic Exporter supporting CSV, XLSX, JSON, and PDF "since reports obviously need all formats eventually." Estimates: for the generic exporter $C_{build} = 20$ h, $C_{carry} = 10$ h/year; the extra formats have combined $p = 0.25$ of all being needed and $S = 24$ h. The CSV-only version is $C_{build} = 4$ h, $C_{carry} \approx 0$ . Walk the full YAGNI decision and give the recommended code shape.

Recall Solution

Step 1 — trigger check. Only CSV has a ticket. XLSX/JSON/PDF are speculative (no present requirement).

Step 2 — inequality on the speculative extra. The generic layer's cost above CSV-only is roughly $(20 - 4) + 10 = 26$ h in year one. Expected saving $p S = 0.25 \times 24 = 6$ h. Is $6 > 26$ ? No → don't build the generic exporter.

Step 3 — build the simplest present thing.

def export_report_csv(report):
    ...  # just CSV, the one ticket

Step 4 — refactor on the Rule of Three. When a second real format lands, still keep them separate; on the third real format, extract an Exporter interface shaped by the three real cases.

Present needs stay in: if this export endpoint receives untrusted parameters, validation and auth are built now — they satisfy a present requirement, and YAGNI never deletes those.

Wrap-up recall

Recall One-line takeaways (cover the right side)

Break-even probability formula? ::: $p^{⋆} = (C_{build} + C_{carry}) / S$ . Why does the "5-minute hook" cost far more than 5 minutes? ::: Because $C_{carry}$ (reading/testing/refactoring by everyone, repeatedly) dominates the one-time build cost. DRY vs YAGNI timing? ::: DRY removes existing duplication; extract only on the third real case (Rule of Three), else you violate YAGNI. Does YAGNI defer validation/auth on a live endpoint? ::: No — those are present requirements, built well now. If $S = 0$ , should you ever build speculatively? ::: No — zero saving can never beat positive certain cost.