The wrong abstraction

A wrong abstraction is born when you merge two things that were only coincidentally alike. Two functions had similar bodies, so someone extracted a shared method. But similar code is not the same as shared meaning. The two callers happened to need the same steps today; they were never the same concept. The extraction couples two requirements that have no reason to change together — and now they are forced to.

// Day 1: these looked identical, so they got merged.
function renderItem(item: Item) {
  return `<li>${item.name}: ${item.price}</li>`;
}
// "invoiceLine looks the same!" → extract a shared formatter.

The mistake is treating structural similarity as evidence of a shared abstraction. It is not. The only real evidence is that the two things change together for the same reason — and you usually cannot know that on day one.

The abstraction then rots by accretion: a boolean (or enum) parameter per new caller. A third caller needs almost the same thing — but with a tweak. The path of least resistance is to add a parameter and an if. Then a fourth. Each addition is locally reasonable and globally catastrophic: the function’s branches multiply, its meaning blurs, and its signature becomes a checklist of unrelated flags.

// Each new requirement bolts on a flag instead of forking.
function render(
  item: Item,
  forEmail: boolean,
  isPreview: boolean,
  legacyMode: boolean,
  skipPrice: boolean,
) {
  if (legacyMode) return renderLegacy(item);
  const price = skipPrice ? "" : `: ${item.price}`;
  if (forEmail) return `<tr><td>${item.name}${price}</td></tr>`;
  if (isPreview) return `<li class="preview">${item.name}${price}</li>`;
  return `<li>${item.name}${price}</li>`;
}

A boolean parameter that selects between two behaviours is a reliable signal: the function is doing two jobs. Four of them means four jobs wearing one name. The flags are the tree-rings of a wrong abstraction.

“Duplication is far cheaper than the wrong abstraction.” DRY serves changeability — not the reverse. Sandi Metz’s rule is the heuristic that resolves this unit’s central tension. Duplication has a known, bounded cost: if the rule changes, you edit it in N places, and the worst case is you miss one. The wrong abstraction has an unbounded, compounding cost: every caller is now coupled to every other caller’s edge cases, every change risks all six call sites, and the tangle gets worse with each “small” addition.

DRY is not a goal in itself. It is a means to the real goal — cheap change. When a “DRY” abstraction makes change more expensive than the duplication would have, DRY has been applied against its own purpose. The senior reading of DRY is: remove duplication of knowledge that changes together. Code that merely looks the same but changes for different reasons is not the kind of duplication DRY is about.

The fix is to inline the abstraction back into every caller — deliberately re-duplicate — then re-derive the real abstraction from the differences you can now see. You cannot find the right seam while the wrong one is hiding the data. So you reverse the extraction: copy the relevant branch of the shared function into each caller, delete the flag that selected it, and let each call site become a small, honest, standalone function again.

// Step A — inline back. Each caller gets just its own branch.
function renderListItem(item: Item) {
  return `<li>${item.name}: ${item.price}</li>`;
}
function renderEmailRow(item: Item) {
  return `<tr><td>${item.name}: ${item.price}</td></tr>`;
}
function renderPreview(item: Item) {
  return `<li class="preview">${item.name}: ${item.price}</li>`;
}

Now the duplication is visible and local. With all three side by side, the genuine shared concept appears: they all format ${name}: ${price} and wrap it differently. That — the inner “name + price” string — is the real abstraction; the wrapping is what legitimately varies.

// Step B — re-derive the TRUE shared concept (the inner content, not the wrapper).
function nameAndPrice(item: Item) {
  return `${item.name}: ${item.price}`;
}
const renderListItem  = (i: Item) => `<li>${nameAndPrice(i)}</li>`;
const renderEmailRow  = (i: Item) => `<tr><td>${nameAndPrice(i)}</td></tr>`;
const renderPreview   = (i: Item) => `<li class="preview">${nameAndPrice(i)}</li>`;

The new abstraction is small, has no flags, and each caller is readable on its own. You did not “give up on DRY” — you found the duplication that actually shares meaning and extracted only that.

Be willing to delete an abstraction. Sunk cost is not a reason to keep the wrong one — and “removing it feels un-DRY” is the failure mode to name and resist. The cost already paid to build the bad abstraction is gone whether you keep it or not; the only question is the cost from here. If the abstraction makes every future change more expensive, keeping it out of loyalty to past effort just pays the cost forever.

The specific trap is identity-based: engineers internalise “DRY = good,” so inlining triggers a “this feels wrong” reflex even when it is plainly correct. Notice the feeling and reframe it: you are not abandoning DRY, you are serving the goal DRY exists for. When NOT to inline: if the abstraction is genuinely right (callers do change together for one reason) and merely awkward, fix it in place — don’t tear down a load-bearing seam because it has a bad name. The skill is telling a coincidental merge from a real one; the tell is whether the callers’ requirements change together.