What is DRY?
Engineering culture and software practice
DRY, or Don't Repeat Yourself, is a principle named by Andy Hunt and Dave Thomas in their 1999 book The Pragmatic Programmer. Their rule is that every piece of knowledge must have a single, unambiguous, authoritative representation within a system. It is about duplicated knowledge and intent, not about deleting every repeated line of code, and it is routinely misapplied to mean the latter, which can do real harm.
What this means
DRY is a warning about keeping the same important fact in more than one place. If a business rule, a policy, a rate or a definition lives in several places, then sooner or later someone will change one copy and forget the others, and your systems will quietly start to disagree. The cure is to give each piece of knowledge one home that everything else refers to.
The crucial and most-missed point is that DRY is about knowledge, not text. Hunt and Thomas mean the same fact, rule or intent expressed in multiple places, potentially in different forms. Two chunks of code can look identical yet represent two genuinely different pieces of knowledge that just happen to resemble each other today and will diverge tomorrow. Merging those is not DRY; it is a trap.
That distinction is why DRY is one of the most quoted and most abused ideas in software. Reduced to "never copy and paste," it pushes people to bundle unrelated things together simply because they look alike, producing something harder to change than the duplication it replaced.
Why it matters
For any organisation, the sharpest version of DRY is the single source of truth. When the same customer eligibility rule is written into a spreadsheet, a policy document, a form and three separate systems, each copy is a future contradiction waiting to happen. When two reports disagree about a number, a DRY violation is very often the reason: the same knowledge was stored twice and the copies drifted apart.
This is not only a coding concern. The same policy paragraph pasted into fourteen different AI prompts is a textbook DRY violation. Change the policy once and you now have thirteen prompts quietly enforcing the old rule. A prompt library with one authoritative version of each policy, referenced everywhere, is DRY applied to knowledge rather than code.
DRY also has a cost side that the slogan hides. Applied without judgement, it drives premature and wrong abstractions: people force two things into one shared component because they look similar, then bend that component with special cases until nobody dares touch it. The empirical literature on duplicated code is more nuanced than the slogan suggests, and sometimes a little duplication is the cheaper, safer choice.
The practical stakes, then, are twofold. Under-applying DRY leaves you with contradictory copies of important facts. Over-applying it leaves you with tangled, over-shared machinery. Leaders benefit from knowing that both failures exist, because vendors and engineers invoke DRY to justify each of them.
How it works
Where the term came from
DRY was named by Andy Hunt and Dave Thomas in The Pragmatic Programmer, first published in 1999, where it appears as one of the book's numbered tips. Their formulation is precise: "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." They apply it deliberately broadly, to database schemas, test plans, build systems and documentation, not just to lines of code.
In the 20th anniversary edition, published in 2019, the authors reflected that the phrase had been oversimplified over the years into a blanket ban on copying and pasting code, and stressed again that they meant duplication of knowledge. Related ideas predate the name: Extreme Programming had a maxim known as Once and Only Once, and avoiding duplication was part of the older Unix philosophy. Hunt and Thomas gave the idea a catchy label and widened its scope.
What knowledge means
The word knowledge is the whole game. A piece of knowledge is a fact or rule about your problem: the VAT rate, the definition of an active customer, the sequence of steps in an approval. DRY says each such fact should have one authoritative home. It does not say that any two passages of code that look alike must be merged. If two things change for different reasons, they are different knowledge, and keeping them separate is correct even when they currently look the same.
The wrong-abstraction problem
The best-known caution comes from software engineer Sandi Metz, whose line "duplication is far cheaper than the wrong abstraction" landed in her 2014 RailsConf talk and was set out in her 2016 blog post The Wrong Abstraction. Her argument is that duplication has an obvious, bounded cost, you change things in more than one place, whereas a wrong shared abstraction has a compounding cost, as maintainers keep bolting on parameters and conditionals until the shared code is an unreadable mess. Her advice when an abstraction stops fitting is counter-intuitive but sound: inline it back into duplication, then let the real pattern re-emerge. Companion heuristics include WET, a joking inversion standing for write everything twice, and AHA, avoid hasty abstractions. The rule of three, popularised in Martin Fowler's Refactoring and attributed there to Don Roberts, offers a rough trigger: wait until you have seen something three times before abstracting it.
What the clone research actually shows
Academic work on code duplication, known as clone research, complicates the slogan. In a widely cited 2008 study in the journal Empirical Software Engineering, titled "Cloning considered harmful considered harmful," Cory Kapser and Michael Godfrey found significant evidence that duplication is often used as a principled engineering tool, for example cloning a subsystem as a sandbox to trial a new feature before merging it back. The lesson is not that duplication is fine, but that whether a clone is harmful depends on why it exists, which is exactly the knowledge-versus-text distinction the original authors intended.
Examples
A mid-sized retailer keeps its returns policy in a help-centre article, a staff handbook, an email template and the checkout page. When the policy changes from thirty to twenty-eight days, three of the four get updated and the checkout page does not. A DRY approach stores the policy once, as a single authoritative text, and has every surface pull from that one source, so a single edit propagates everywhere.
A council department runs two systems that each calculate a discount using their own copy of the same rule. Over a couple of years the rules drift, and residents doing the same thing get different answers depending on which system served them. The fix is to make one service the authoritative owner of that rule and have the other consult it, rather than each holding a private copy that can silently diverge.
A charity building an AI assistant pastes the same safeguarding paragraph into a dozen prompts across its prompt library. When the safeguarding wording is revised, several prompts keep the old text. Applying DRY to prompts, the charity keeps one canonical safeguarding block and references it, so the policy has a single home and updates in one move.
Common misunderstandings
DRY means never copy and paste code. It does not. The authors mean duplicated knowledge, and in the 20th anniversary edition they explicitly complained that the phrase had been narrowed into a blanket prohibition on copying. Identical-looking code that represents different rules is not a DRY violation.
Removing duplication is always an improvement. It is not. Sandi Metz's point is that the wrong abstraction costs more over time than the duplication it replaced, because shared code accretes special cases until it is unmaintainable. Sometimes reintroducing duplication is the right move.
DRY is only about code. It is not. Hunt and Thomas apply it to schemas, documentation, configuration and process, and its most valuable business use is a single source of truth for policies, numbers and prompts rather than anything in a codebase.
This is the same thing as a code smell. It is not. The existing Code smell article describes duplicated code as a surface symptom that something may be wrong, drawn from Fowler and Beck. DRY, by contrast, is the underlying principle about where knowledge should live and why; a smell points at a possible problem, whereas DRY tells you what good looks like and warns that fixing the smell badly can be worse than the smell.
More abstraction is always more DRY. It is not. Piling on shared layers can violate the spirit of DRY by fusing knowledge that should stay separate, creating rigidity rather than a single clear source of truth.
Risks and boundaries
DRY is misapplied most often as a licence to abstract early and aggressively. The folklore, don't repeat yourself, ever, outruns both the authors' intent and the evidence. The clone research shows that duplication is sometimes a deliberate, sensible tactic, and the wrong-abstraction argument shows that over-sharing has a real and compounding price. The genuine debate is not whether to avoid duplication but when, and how to tell duplicated knowledge from coincidental resemblance.
There are clear boundaries. DRY does not tell you to eliminate every repeated word or number regardless of meaning; performance, clarity or genuine independence can all justify keeping two similar things apart. It also does not, on its own, tell you which copy should be authoritative, which is a design decision that needs human judgement. And in prose, policy and prompts, an over-zealous single source can become a bottleneck if the one owner is slow to update or hard to reach. DRY is a strong guide to where knowledge should live, not a rule to be applied mechanically.
What to do next
Find your duplicated knowledge before your code. Ask where the same policy, rate or definition currently lives in more than one document, spreadsheet or system, because that is where contradictions are already forming.
Name a single source of truth for each important fact. For every rule that matters, decide which document or system is authoritative and have the others reference it rather than hold private copies.
Treat your prompt library the same way. If the same policy text is pasted into many prompts, consolidate it into one canonical block that prompts point to, so a change happens once.
Let your technical people apply DRY to knowledge, not text. Encourage them to resist merging code that merely looks alike, and to reintroduce duplication when a shared component has become a tangle of special cases.
Use a simple trigger for abstraction. Adopt the rule-of-three habit: wait until something recurs a third time before combining it, so you are abstracting a real pattern rather than a coincidence.
FAQs
What does DRY stand for?
Don't Repeat Yourself. It was named by Andy Hunt and Dave Thomas in their 1999 book The Pragmatic Programmer, where they state that every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
Is DRY only about code?
No. The authors apply it to schemas, documentation, configuration and process. Its most useful business form is a single source of truth for policies, numbers and AI prompts, not just for anything in a codebase.
What is the wrong abstraction?
A shared piece of code or logic that was extracted from things that looked similar but were not truly the same. Sandi Metz argues it costs more than duplication because it accumulates special cases until nobody can safely change it.
What are WET and AHA?
They are counter-slogans. WET jokingly stands for write everything twice, a reminder not to over-apply DRY. AHA stands for avoid hasty abstractions, advising you to wait until a pattern is clear before combining code.
Does research support avoiding all duplication?
No. A 2008 study by Kapser and Godfrey in Empirical Software Engineering found duplication is often used as a principled tool, such as sandboxing a new feature, so whether a clone is harmful depends on why it exists.
How is DRY different from a code smell?
A code smell such as duplicated code is a surface symptom that something may be wrong. DRY is the underlying principle about where knowledge should live, and it warns that fixing the smell with the wrong abstraction can be worse than leaving it.
When is duplication actually the right call?
When two things merely look alike but change for different reasons, or when merging them would create a tangled, over-shared component. In those cases keeping separate copies is clearer and cheaper to maintain.