DRY (Don't Repeat Yourself) is the principle from Andy Hunt and Dave Thomas's The Pragmatic Programmer (1999) that every piece of knowledge must have a single, unambiguous, authoritative representation within a system. It targets duplicated knowledge and intent, such as a business rule or a schema, not code that merely looks alike. Other artifacts are derived from one source of truth, and abstraction waits for the Rule of Three, because the wrong abstraction costs more than duplication.

DRY (Don’t Repeat Yourself)

Details
Full Name

Don’t Repeat Yourself

Also known as

DRY Principle; antonym: WET ("Write Everything Twice" / "We Enjoy Typing")

Core Concepts:

The principle

"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." One fact — a business rule, a constant, a schema — lives in exactly one place

Knowledge, not code

DRY targets duplicated knowledge/intent, not coincidental textual similarity. Two code fragments that look alike but change for different reasons are not a DRY violation; collapsing them couples unrelated concerns

Single source of truth

Derive rather than restate — generate docs/config/clients from one authoritative definition so a change propagates instead of being copied

Rule of Three

Extract a shared abstraction after the third occurrence, not the first (Martin Fowler). Premature de-duplication guesses at an abstraction before the pattern is clear

The wrong-abstraction caution

"Duplication is far cheaper than the wrong abstraction" (Sandi Metz). A bad shared abstraction couples callers and is harder to unwind than the duplication it removed — prefer duplication until the right seam is obvious

Key Proponents

Andy Hunt & Dave Thomas, The Pragmatic Programmer (1999)

When to Use:

  • Consolidating a business rule, constant, or schema that appears in several places

  • Designing a single source of truth (config, types, API contracts) that other artifacts derive from

  • Reviewing code for knowledge duplication that causes change to require edits in many spots

When NOT to Use:

  • Before the Rule of Three — resist abstracting on the first or second occurrence

  • When two similar fragments change for different reasons — coupling them via a shared abstraction is worse than the duplication

  • As dogma over readability: a little duplication can beat a leaky, over-general abstraction

Criticism:

  • Sandi Metz, "The Wrong Abstraction" (2016) — overzealous DRY produces abstractions that later requirements don’t fit: "duplication is far cheaper than the wrong abstraction"; her advice is to re-introduce the duplication until the right abstraction reveals itself

  • The authors themselves concede the principle is widely misread: in the 20th Anniversary Edition (2019), Thomas & Hunt write they "did a poor job of explaining" DRY — it targets duplication of knowledge and intent; code deduplication is "a tiny and fairly trivial part" (official chapter extract)

  • The corollary both critiques share: two pieces of code that look alike but encode different business knowledge are not a DRY violation — merging them creates coupling, not clarity