apply-dry-principle

Apply DRY Principle

Every piece of knowledge must have a single, authoritative representation in the system.

Why This Is Best Practice

Adopted by: Industry-universal. Codified in "The Pragmatic Programmer" (500k+ copies sold), cited in Google Engineering Practices, Microsoft internal style guides, and Stripe's engineering handbook. No top-tier engineering org advocates for deliberate duplication. Impact: Every duplicated piece of knowledge is a latent defect — a future change must be applied N times, and the probability of missing one instance scales with N. DRY reduces the change surface proportionally. In large codebases, duplicated business logic is the leading cause of behavioral divergence between services. Why best: DRY addresses knowledge duplication, not just code copy-paste. A business rule encoded in a database constraint, an API validator, and a frontend form is triplicated knowledge — changing the rule requires three coordinated edits, each a defect opportunity. WET (Write Everything Twice) produces inconsistency at scale.

Sources: Hunt & Thomas, "The Pragmatic Programmer" ch. 7 (The Evils of Duplication); Google Engineering Practices; Martin Fowler, "Refactoring" (2018 ed.), ch. 3

Steps

1. Classify the duplication type

Type	Example	Risk
Code	Same function copy-pasted	Low — caught by linters
Data	Magic number repeated	Medium — one instance gets updated
Logic	Business rule in 3 places	High — behavioral drift
Knowledge	Same concept with different names	Critical — silent divergence

2. Find the authoritative location

Ask: "If this knowledge changes, what is the ONE place I'd update?" That location should be the source of truth. Everything else should reference it.

3. Extract to the right abstraction level

Match the extraction scope to the duplication scope:

Duplication scope	Extraction
Within a function	Named constant or local variable
Within a module	Private function
Across modules in a service	Shared utility / helper
Across services	Shared library, schema registry, or API contract
Across frontend and backend	Code generation from a single schema (e.g., OpenAPI, Protobuf)

4. Replace all instances

Replace every occurrence with a reference to the extracted source. Verify with grep or your IDE's find-all-references — missing one instance recreates the problem.

5. Verify single-edit guarantee

Make a hypothetical change: "If this knowledge changes, how many edits are required?" The answer should be exactly one. If it's more, the extraction is incomplete.

Rules

• Rule of Three: Don't extract after the first or second occurrence — wait for the third. Premature extraction creates the wrong abstraction, which is harder to fix than duplication.
• Coincidental similarity ≠ shared knowledge: Two functions that look the same but represent different concepts should NOT be merged — they will diverge.
• Test duplication is acceptable: Tests often repeat setup for clarity. DRY tests can obscure what each test actually verifies. Prefer duplication in tests over abstraction that hides intent.
• Don't DRY across service boundaries without a contract: Sharing code between services via copy-paste is often correct; sharing via a live dependency creates coupling. Prefer generating both from a single schema.

Common Mistakes

Abstracting coincidental similarity. Two functions that compute totals for orders and invoices look the same today. Next quarter, order totals add tax; invoice totals don't. Premature merging forces an ugly split or a flag parameter.

DRY the wrong layer. Deduplicating SQL queries by sharing a query builder object couples unrelated features. The duplication was in SQL text, not in knowledge.

Forgetting knowledge duplication across systems. API documentation that duplicates the API implementation is duplicated knowledge — use code generation or contract-first design to keep one authoritative source.

When NOT to Use

• When two similar things represent genuinely different concepts (coincidental similarity)
• When the abstraction would require a flag parameter to handle variants — this signals the wrong abstraction; keep them separate
• In tests where duplication aids readability and independence
• When deduplication would introduce a cross-service dependency where a schema/contract doesn't already exist