Visual walkthrough — Code review — what to look for

---

Step 1 — What is a "bug," and what does it cost?

WHAT. Imagine a single mistake hiding in your code. Call it a bug. It sits there quietly until someone notices it. The moment of noticing happens at some stage of the pipeline.

WHY stages matter. A bug caught while a human is reading the diff is cheap to fix — you just edit a line before anything ships. The same bug caught after real users hit it is a disaster: now there's an outage, a hotfix, an apology email. Same bug, wildly different price. So the first thing we need is a number for "how much does fixing this bug cost, given where we caught it?"

We name three stages with a counter $s$ (just an index, $s=0,1,2$):

• $s=0$ — caught at review (a human reads the change before merge)
• $s=1$ — caught in QA (automated/manual testing after merge)
• $s=2$ — caught in production (real users already hit it)

PICTURE. Look at the staircase. Each step to the right is one stage later, and the height — the cost — jumps by a fixed multiplier each time, not by a fixed amount. That "multiply, don't add" shape is the whole reason review exists.

---

Step 2 — Turning the staircase into a formula

WHAT. We claimed the cost multiplies by $k$ each stage. Let's write that down.

• At $s=0$: cost $=c_0$ (one baseline unit).
• At $s=1$: cost $=c_0\times k$ (one stage later, so times $k$ once).
• At $s=2$: cost $=c_0\times k\times k=c_0{k}^2$.

The pattern — multiply by $k$ once per stage — is exactly what raising to a power means. $k^s$ is shorthand for "$k$ multiplied by itself $s$ times."

$${\text{cost}}_{\text{fix}}=\underset{\begin{array}{c}\text{baseline}\\ \text{one bug at review}\end{array}}{\underbrace{c_0}}\cdot \underset{\begin{array}{c}\text{multiplier applied}\\ s\text{ times, once per stage}\end{array}}{\underbrace{k^s}}$$

WHY a power and not, say, $c_0+ks$ (adding)? Because each stage doesn't add a fixed extra cost — it re-scales everything. A production bug isn't "review cost plus a bit"; it's review cost blown up by the whole downstream machine (deploys, users, incident response). Repeated scaling is exponentiation. Using addition here would badly underestimate the pain of late bugs — the exact mistake that makes teams skip review. See Big-O notation for the same "growth shape matters more than the constant" idea in a different setting.

PICTURE. Two curves on the same axes: the straight line "if cost only added" versus the curve "cost multiplies." They start together at $s=0$ and the multiplying curve rockets away. That gap is the danger you're insuring against.

---

Step 3 — A change has many bugs, not one

WHAT. One code change (a "diff", the thing you review in Pull requests and Git workflow) rarely holds exactly one bug. Let $n$ be the number of hidden bugs it carries — latent meaning "present but not yet noticed."

WHY introduce $n$. We want the cost of reviewing this whole change, so we must total up across all its bugs. $n$ is the scale of the risk: a tiny typo-fix might have $n\approx 0$; a gnarly 600-line feature might have $n=5$.

PICTURE. A box labelled "the diff" with several red bug-dots inside it. We're about to ask: of these $n$ dots, how many does a reviewer actually catch?

---

Step 4 — Reviewers are good, but not perfect: the probability $p$

WHAT. A reviewer doesn't catch every bug — nobody does. So we attach a probability $p$ to each bug: the chance the reviewer spots it. $p$ is a number between $0$ and $1$.

• $p=1$ → a perfect reviewer catches everything.
• $p=0$ → the reviewer catches nothing (same as no review).
• $p=0.7$ → on average, $7$ of every $10$ bugs get caught.

WHY probability and not a yes/no? Because "will this reviewer catch this bug?" isn't fixed — it depends on the bug, their focus, the hour. When an outcome is uncertain and we want the average over many tries, probability is the right tool. Multiplying a count by a probability gives an expected count — the long-run average.

So out of $n$ bugs:

$$\underset{\text{expected bugs caught}}{\underbrace{np}}\underset{\text{expected bugs that escape}}{\underbrace{n(1-p)}}$$

The term $1-p$ is "the chance of not catching," because caught and not-caught are the only two options and their probabilities must sum to $1$.

PICTURE. The same box of bug-dots, now split by a dashed line: green dots on the "caught at review" side ($np$ of them), red dots leaking out the "escaped to production" side ($n(1-p)$). A better reviewer slides that dashed line to trap more green.

---

Step 5 — Add up the cost with a review

WHAT. Now total the bill when you do review. Two groups of bugs, each with its own price from Step 2:

$$E_{\text{review}}=\underset{\text{caught}}{\underbrace{np}}\cdot \underset{\text{price at }s=0}{\underbrace{c_0}}+\underset{\text{escaped}}{\underbrace{n(1-p)}}\cdot \underset{\text{price at }s=2}{\underbrace{c_0{k}^2}}+\underset{\begin{array}{c}\text{reviewer’s}\\ \text{time cost}\end{array}}{\underbrace{R}}$$

Term by term:

• $np\cdot c_0$ — the caught bugs, each fixed cheaply at review ($s=0$, so cost $c_0$).
• $n(1-p)\cdot c_0{k}^2$ — the escapees, each hitting production ($s=2$, so cost $c_0{k}^2$).
• $R$ — the price of the review itself: the reviewer's hours. This is what review costs you.

WHY the "$E$" (expected). Because these are average costs over many changes — probabilities gave us averages, not certainties. $E$ just means "expected value," the long-run mean bill.

PICTURE. A stacked bar: a short green block (cheap caught bugs) + a taller amber block (the escapees, expensive) + a thin block on top for $R$. That's your total when you review.

---

Step 6 — The cost of skipping review

WHAT. Now the lazy path: no review. With no one reading the diff, every bug sails through to production. That's $n$ bugs, each at the $s=2$ price:

$$E_{\text{none}}=\underset{\text{all of them}}{\underbrace{n}}\cdot \underset{\text{production price}}{\underbrace{c_0{k}^2}}$$

WHY it's this simple. No review means $p=0$: nothing caught, nothing costs the cheap $c_0$, and there's no reviewer bill $R$. Set $p=0$ in Step 5's formula and it collapses exactly to this — a nice consistency check that our two worlds share the same physics.

PICTURE. One tall amber bar — all bugs at full production price, no green savings block at all. Put it next to Step 5's bar and the comparison is the whole argument.

---

Step 7 — When is reviewing worth it? Do the algebra

WHAT. Review pays off exactly when reviewing is cheaper than skipping:

$$E_{\text{review}}<E_{\text{none}}$$

Substitute both:

$$np{c}_0+n(1-p)c_0{k}^2+R<n{c}_0{k}^2$$

Now isolate $R$ (the one knob you can't easily change — the reviewer's time). Move everything that isn't $R$ to the right:

$$R<n{c}_0{k}^2-np{c}_0-n(1-p)c_0{k}^2$$

Look at the two $k^2$ terms. $n{c}_0{k}^2-n(1-p)c_0{k}^2=n{c}_0{k}^2[1-(1-p)]=n{c}_0{k}^{2}p$. The bracket collapsed because $1-(1-p)=p$. So:

$$R<np{c}_0{k}^2-np{c}_0=np{c}_0(k^2-1)$$

We factored out the common $np{c}_0$ from both terms, leaving $(k^2-1)$. Done.

$$\boxed{R<np{c}_0(k^2-1)}$$

WHY this form is the good one. Every symbol on the right is a lever you can name:

• $n\uparrow$ (riskier change) → right side grows → review pays more.
• $p\uparrow$ (better reviewer) → right side grows → review pays more.
• $k\uparrow$ (production failures more brutal) → $(k^2-1)$ grows fast → review pays much more.

If your change is trivial ($n\approx 0$) or your reviewer is asleep ($p\approx 0$), the right side shrinks toward $0$ and review stops being worth its time $R$ — the formula honestly tells you when not to bother.

PICTURE. A balance scale: left pan holds $R$ (reviewer time); right pan holds $np{c}_0(k^2-1)$ (the disaster you avoid). When the right pan is heavier, review wins.

---

Step 8 — Edge and degenerate cases (never skipped)

Every good derivation must survive its extremes. Check the corners:

Case	What it means	Right side $np{c}_0(k^2-1)$	Verdict
$n=0$	change has no bugs	$0$	never worth $R>0$ — pure overhead
$p=0$	reviewer catches nothing	$0$	review is theatre; fix your reviewers
$k=1$	late bugs cost the same as early	$(k^2-1)=0$ → $0$	if lateness is free, don't review
$k>1$, $n,p>0$	the real world	positive, grows with $k^2$	review pays, more so as $k$ rises
$p=1$	perfect reviewer	$n{c}_0(k^2-1)$, the max	biggest possible payoff

WHY these matter. The $k=1$ row is the secret assumption people forget: review only pays because late bugs are dramatically more expensive than early ones. In a world where a production bug cost the same as a review bug ($k=1$), the whole practice would be pointless. It's the exponential cost, not review magic, that justifies review. This is also why sprawling PRs are dangerous: past ~200–400 lines a reviewer's effective $p$ drops, shrinking the right side even though the true $n$ is higher — the worst combination. Split them (see Refactoring and Technical debt for why smaller changes stay reviewable).

PICTURE. The right-hand-side value plotted against $k$, with the $k=1$ zero-crossing marked in amber and the steep $k^2$ climb beyond it. Left of the marker: don't review. Right: review harder as $k$ grows.

---

The one-picture summary

Everything above, compressed: bugs flow out of a change; a reviewer (probability $p$) diverts $np$ of them into the cheap $c_0$ bin and lets $n(1-p)$ leak into the $c_0{k}^2$ bin; the balance scale weighs your reviewer time $R$ against the disaster avoided $np{c}_0(k^2-1)$.

Recall Feynman retelling — say it like you're 12 (click to reveal)

Pretend every bug is a leak in a boat. If you find a leak while the boat's still on the trailer ($s=0$), you dab it with glue — easy. If you find it once you're far out at sea ($s=2$), you're bailing water in a storm — the same leak, but now it costs a hundred times more, because each stage away from shore multiplies the trouble by about ten ($k^2=100$).

A code reviewer is a friend who checks the boat on the trailer. They won't spot every leak — maybe $7$ out of $10$ ($p=0.7$) — but every one they catch is a hundred-times-cheaper fix. It costs a bit of their time ($R$) to look. The rule for "is it worth it?" is just common sense written in math: if the time to check is less than the disaster you'd otherwise face, check. The more leaks the boat has, the sharper your friend's eyes, and the stormier the open sea, the more obviously worth it that check becomes. And if the boat's a bathtub toy with no leaks and the sea is a puddle where leaks cost nothing? Then don't bother — the math says so too.

Recall

The master inequality, and what makes each side move ::: $R<np{c}_0(k^2-1)$; right side grows with more bugs $n$, a better reviewer $p$, and costlier late failures $k$. Why exponent $k^s$ and not addition $c_0+ks$ ::: each stage re-scales the whole downstream cost (deploys, users, incidents), and repeated scaling is exactly exponentiation. Why $E_{\text{none}}=n{c}_0{k}^2$ ::: no review means $p=0$, so every bug reaches production ($s=2$) at price $c_0{k}^2$; set $p=0$ in the review formula and it collapses to this. The one case where review never pays ::: whenever the right side is $0$ — i.e. $n=0$, or $p=0$, or $k=1$ (late bugs no more expensive than early ones).

---

Connections

• Parent: Code review — what to look for — the priority ladder this cost model justifies.
• Big-O notation — same lesson: the growth shape ($k^s$) dominates the constants.
• Pull requests and Git workflow — the diff is the unit whose $n$ and $p$ we modelled.
• Unit testing — tests raise effective $p$ by catching escapees before production.
• Technical debt · Refactoring — small changes keep $p$ high; giant PRs crush it.
• SQL injection and input validation — a single missed security bug is a high-$k$ escapee.