Don't Repeat Yourself (DRY)

Every piece of knowledge in a system has one authoritative home. DRY is about facts and rules, not about lines of code that happen to look alike.

Overview

DRY stands for Don't Repeat Yourself. Andy Hunt and Dave Thomas named it in The Pragmatic Programmer (1999): every piece of knowledge in a system should have a single, unambiguous, authoritative representation. Thomas has said the principle is widely misread as 'do not duplicate code'. It is about knowledge: a business rule, a limit, a format, a schema, a mapping. If that knowledge lives in two places, one day the two will disagree, and the bug will be found by a customer.

The mirror image matters just as much. Two pieces of code can look identical and still encode different knowledge, and merging them creates a coupling that hurts more than the duplication did. A strong interview answer shows both halves: you remove duplicated knowledge without hesitation, and you leave look-alike code alone until it proves it is the same thing.

One home for each fact

Duplication of knowledge shows up in more places than copied functions.

Code — The same discount rule in two services — One function or module both call
Constants — A limit typed as a number in five files — One named constant
Validation — The same email check in the form and the API — One shared rule; the API is the authority
Schema — A stored total that can be computed from the rows — Compute it, or store it in one place with a clear owner
Configuration — Timeouts copied into every service's config — One config source the services read
Documentation — A comment that restates the code — Let the code say it; document the why

Knowledge versus text

The test is not 'do these lines look the same' but 'would these two places always change together, for the same reason'. If yes, they are one piece of knowledge and belong in one place. If they could change separately, they only happen to look alike today.

Would a change to one always require the same change to the other? — Yes — No
Do they serve the same business rule? — Yes — Different rules with similar shapes
Who asks for changes? — The same owner — Different owners or teams
Example — Tax rate used in checkout and in invoices — Address formatting for customers and for warehouses

The rule of three and the wrong abstraction

Two heuristics keep DRY from turning into premature abstraction. The rule of three, popularized in Martin Fowler's Refactoring (1999), says the first time you write something you just write it, the second time you notice the duplication but tolerate it, and the third time you refactor. By then you have seen enough variation to know what the shared part really is.

Sandi Metz's essay The Wrong Abstraction (2016) describes what happens when you abstract too early: a later developer meets a case that almost fits, adds a parameter and a branch, the next developer adds another, and the once-simple helper becomes a maze of conditions. Her advice is that duplication is far cheaper than the wrong abstraction, and when you find one, inline it back into its callers and start over.

Rule of three — Extract on the third occurrence, not the second — Abstracting before you know the shape
The wrong abstraction — Prefer duplication to a bad shared helper; inline and re-extract when it goes wrong — Sunk cost: keeping a helper because it took effort
Knowledge test — Merge only what changes together — Coupling unrelated rules

What you will be able to do

Define DRY as knowledge, not code, and give examples beyond copied functions.
Tell true duplication from accidental duplication and justify each call.
Apply the rule of three and explain what an early abstraction costs.
Spot DRY violations across a stack: validation, constants, schemas, contracts.
Explain how DRY and the single responsibility principle work together and where they pull apart.

Interview questions

What is DRY really about, and what does a violation look like?
When does applying DRY make a codebase worse?
How do you apply DRY across a whole stack?
How does DRY relate to the single responsibility principle?
Does DRY apply to data and schemas?