What does the DRY principle ("Don't Repeat Yourself") actually require, and why is it stated in terms of knowledge rather than lines of code?

## The definition DRY was coined by Andy Hunt and Dave Thomas in *The Pragmatic Programmer* (1999): > **Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.** Unpack each word: - **Knowledge** — a fact or rule about the problem or the system. Examples: "orders over 100 ship free", "a username is 3–32 characters", "the retry budget is 3 attempts", "the date on the wire is ISO-8601 UTC". Knowledge is *semantic*; it is not the same as text. - **Single** — exactly one place owns it. - **Unambiguous** — you can point at that place and say "this is the rule"; there is no second candidate that might also be the rule. - **Authoritative** — everything else *derives* from it (calls it, imports it, is generated from it) rather than restating it. - **Within a system** — the scope matters. Two separately deployed systems that each know a rule are a different (and often acceptable) situation from two functions in one module that each know it; see the trade-off section. ## Why "knowledge", not "lines" The common misreading is "never write the same characters twice". That leads to two symmetric mistakes. **Mistake 1 — false positives (coincidental duplication).** Two snippets look identical today but encode *different* rules that happen to agree right now: ``` validateUsername(s): return 3 <= len(s) <= 32 validateNickname(s): return 3 <= len(s) <= 32 ``` These are two independent policies. Merging them into one shared `validateShortName` creates *coupling*: the day product says nicknames may be 64 chars, you either break usernames or add a flag parameter, and the "shared" function starts sprouting `if kind == ...` branches. That is a wrong abstraction — the change that DRY was supposed to make cheap has become expensive instead. **Mistake 2 — false negatives (hidden duplication).** The same rule is expressed in places that share no text at all: - a database `CHECK` constraint, a server-side validator, a client-side form regex, and a paragraph in the API docs all restating "3–32 characters"; - an `enum` in code and a lookup table in the database listing the same statuses; - a struct definition and a hand-written JSON parser that must agree field by field; - a build script and a Dockerfile that each hardcode the port. No copy-paste occurred, yet a single change to the rule requires coordinated edits in four repositories. This is the expensive kind of duplication, and grep will not find it. ## The operational test A practical way to decide, without philosophy: > **If this rule changes, must all these places change *together*, *always*, *for the same reason*?** - **Yes, always, same reason** → one piece of knowledge, duplicated. Fix it. - **They might change independently, for different reasons** → two pieces of knowledge that currently coincide. Leave them alone. This is the same test as the Single Responsibility Principle's "one reason to change", applied to duplication. Robert Martin's framing helps: duplication between code owned by *different actors* (different stakeholders who request changes) is usually **false** duplication and should be left duplicated. ## How you remove real duplication Extracting a function is only the most obvious tool. The full menu: | Kind of knowledge | Single-source technique | |---|---| | Behaviour / algorithm | function, method, module | | Value / magic number | named constant, config entry | | Shape of data | one type/schema; generate DTOs, validators, docs, and client SDKs from it (e.g. one interface-definition file) | | Structural repetition across many types | generics/parameterisation, code generation, macros | | Same rule in DB + app | constraint owned in one place, the other derived or tested against it | | Knowledge in prose | generate docs from the code, or test the docs' examples so drift fails the build | Note the pattern: when you genuinely cannot collapse two representations (a database constraint and a client-side check must both physically exist for performance and UX reasons), DRY is preserved by **derivation** — generate one from the other — or, failing that, by an **automated consistency check** that fails loudly when they drift. Duplication you cannot remove should at least be duplication you cannot *silently* break. ## Costs and limits Deduplication is not free; it converts duplication into **coupling**. Every caller of the shared thing is now affected by changes to it. So the cost model is: - **Cost of duplication**: divergent change (a bug fixed in 3 of 4 copies), inconsistent behaviour, more code to read. - **Cost of the wrong abstraction**: a shared component that must serve incompatible needs; parameter creep, conditional branches, ripple failures across unrelated features, and painful un-merging later. Sandi Metz's much-quoted rule of thumb — *"duplication is far cheaper than the wrong abstraction"* — is a reaction to teams that pay cost #2 to avoid cost #1. Related counterweights are the **rule of three** (wait for a third occurrence before extracting) and **AHA** ("Avoid Hasty Abstractions", Kent C. Dodds), which say: prefer to *wait* until the shape of the variation is known, because inlining a premature abstraction is harder than extracting a late one. Also note deliberate DRY exceptions: - **Tests** tolerate more repetition than production code; an explicit, obvious test that restates values is often better than a clever shared fixture, because tests are specifications you read one at a time. - **Across service or team boundaries**, a shared library that encodes business rules couples independent deploy cycles; many architectures deliberately duplicate small amounts of logic to keep autonomy ("prefer duplication over the wrong coupling" is a standard microservice guideline). ## Summary DRY is about *one authoritative source per fact*, enforced ideally by structure (call/derive/generate) and at minimum by an automated check. It is not a mandate to compress text, and it is not unconditional: it trades duplication risk against coupling risk, and a good engineer names which risk they are choosing and why.