The rule of three

Two occurrences don’t reveal the axis of variation — three do. An abstraction is a claim: “these cases are the same except along this one axis.” With one occurrence you have no axis at all. With two, you can see a difference, but you can’t tell whether it’s the difference — the dimension future cases will actually vary along — or just an accident of these particular two.

// Occurrence #1
function priceForBook(b: Book) {
  return b.basePrice * 1.2; // VAT
}

// Occurrence #2 — looks like the same shape with a different rate
function priceForEbook(e: Ebook) {
  return e.basePrice * 1.07; // reduced VAT
}

Tempting to extract priceWith(rate). But is rate the real axis? Or will the next case vary by region, by customer type, by promotional override? Two points define a line, and a line through two points always fits perfectly — which is exactly why it tells you nothing about where the third point lands.

Premature abstraction guesses the axis wrong, then ossifies the wrong shape. The danger isn’t the wasted effort of extracting early — it’s that the early abstraction commits you. Once three callers depend on priceWith(rate), that signature is load-bearing. When the real variation turns out to be regional tax tables, you can’t just change the abstraction; you have to fight it: add a second parameter, thread a flag, special-case one caller, and the helper accretes complexity to cover a shape it was never designed for.

// What "extract on the second" decays into by the fifth caller:
function price(base: number, rate: number, region?: Region,
               isExempt?: boolean, override?: number) {
  if (override != null) return override;
  if (isExempt) return base;
  const r = region ? rateFor(region) : rate; // the original `rate` is now vestigial
  return base * r;
}

Every flag is scar tissue from a wrong guess. The abstraction now obscures more than it shares.

Duplication is cheaper than the wrong abstraction — until the pattern is clear. This is the senior inversion of the junior instinct. Junior reasoning: “duplication is always bad, eliminate it now.” Senior reasoning: duplication has a known, bounded cost — N copies, each editable in place, each independently correct. The wrong abstraction has an unknown, growing cost — every caller is now coupled through a shape that doesn’t fit, and untangling it is harder than if they’d stayed apart, because you must first re-inline the abstraction before you can split it correctly.

So the rule of three is a bet on cost asymmetry: paying the small, visible cost of duplication for one more occurrence buys you the information to abstract correctly — and a correct abstraction is the only one worth its indirection. Waiting is the cheaper move precisely because you don’t yet know enough to be right.

The exception: obvious knowledge duplication is not “waiting for a third example.” The rule of three governs structural similarity — code that happens to look alike but whose shared concept is still unproven. It does not license copy-pasting a fact you already know is single-sourced. A tax rate, a regulatory threshold, a magic API path, a business rule with one true value — these are knowledge duplication, and the third, fourth, and twelfth copy don’t reveal anything new. You already know it’s one concept.

// NOT a rule-of-three candidate — this is one fact, copied:
const fee = subtotal * 0.029 + 30;   // billing.ts
const fee = subtotal * 0.029 + 30;   // refund.ts
const fee = subtotal * 0.029 + 30;   // report.ts   ← 0.029 in 12 files is a bug waiting to drift

Hiding behind “rule of three” to avoid naming STRIPE_FEE is a misuse. The rule defers abstraction when the pattern is uncertain; it never defers de-duplicating a value you can already name. The test: can you give the shared thing a true, stable name right now? If yes, it’s knowledge — extract it. If the only honest name is doTheSimilarThing, the axis isn’t clear yet — wait.