The Core Idea
One Piece of Knowledge, One Place It Lives
The DRY (Don't Repeat Yourself) principle states that every distinct piece of knowledge or logic in a system should have a single, authoritative, unambiguous representation — not that you should never write similar-looking code twice, but that a specific PIECE OF KNOWLEDGE (a business rule, a calculation, a specific fact about how the system should behave) shouldn't be independently duplicated in multiple places.
The real danger of violating DRY isn't the extra typing — it's what happens later, when that piece of knowledge needs to CHANGE. If it's duplicated in five places, all five need to be found and updated correctly and consistently; missing even one creates a subtle, often hard-to-detect inconsistency where the system now behaves differently depending on which copy of the logic happens to run.
💡 Memory Trick
Picture a company's tax rate written directly into 20 different spreadsheets across different departments, instead of stored once in a single shared reference document that all 20 spreadsheets pull from. The day the tax rate changes, someone has to remember to track down and correctly update all 20 separate copies — and if even one spreadsheet gets missed, that department is now silently calculating taxes incorrectly, with no obvious warning that anything is wrong.
Recognizing DRY Violations
It's About Knowledge, Not Just Matching Text
1
Duplicated Business Logic
The same rule or calculation (like 'apply a 10% discount for orders over $100') implemented independently in multiple places — a checkout page, an admin order-editing tool, and a nightly reporting script — is a DRY violation, even if the actual code in each location looks slightly different, because it's the same underlying KNOWLEDGE duplicated three times.
2
Duplicated Configuration Values
The exact same constant or configuration value (like a specific API endpoint URL, or a maximum file upload size) hardcoded in multiple separate files, rather than defined once in a single shared configuration location that everything else references.
3
Not Every Similar-Looking Code Is a DRY Violation
Two pieces of code that happen to LOOK similar right now, but represent genuinely different, independently-evolving pieces of knowledge that just happen to coincide today, are NOT necessarily a DRY violation — forcing them into one shared abstraction prematurely can create a different, equally serious problem: an overly rigid abstraction that has to awkwardly accommodate both use cases as they inevitably diverge over time.
The Balance
DRY Is About Knowledge Duplication, Not Code-Length Minimization
A common misapplication of DRY is aggressively eliminating any code that merely LOOKS similar, even when the underlying reasons for that similarity are coincidental rather than representing genuinely shared knowledge — this often produces a premature, overly-generalized abstraction that becomes awkward and fragile the moment the two originally-similar cases need to evolve independently, since they're now artificially forced to share one implementation.
The practical test isn't 'does this code look the same as that code' — it's 'if this specific piece of knowledge changed, would I need to update it in more than one place, and would that duplication genuinely represent the SAME underlying fact or rule, not just a coincidental resemblance?' If the answer is yes, that's a genuine DRY violation worth fixing; if the resemblance is coincidental and likely to diverge over time, forcing a shared abstraction can do more harm than good.
🖥️ Applied Scenario
A company's shipping cost calculation logic (based on weight, distance, and a fixed handling fee) is independently implemented in both the website's checkout page and a separate internal order-management tool, and a shipping rate change needs to be applied.
1
The developer updates the shipping calculation logic on the website's checkout page, testing thoroughly and confirming the new rates display correctly there.
2
Weeks later, customer service reports that orders placed through the internal order-management tool are still being charged the OLD shipping rates — the developer had forgotten that this exact same calculation logic was independently duplicated there as well.
3
The team refactors both locations to call a single shared shipping-calculation function instead, defined once in a central shared module that both the website and the internal tool import and use.
4
Conclusion: the next time shipping rates change, updating that one shared function automatically and correctly updates behavior everywhere it's used, eliminating the exact class of bug that caused the original inconsistency.
📌 Exam Application
Exam questions frequently present a scenario involving duplicated logic across a codebase and ask you to explain the specific risk this creates (typically, an update applied to one copy but missed in another, causing inconsistent behavior). You may also be asked to distinguish a genuine DRY violation (duplicated KNOWLEDGE) from coincidentally similar-looking code that doesn't actually represent the same underlying rule.
⚠️ Most Common DRY Principle Mistakes
The most common mistake is applying DRY purely at the level of 'this code looks the same as that code' without asking whether it represents the same underlying KNOWLEDGE — two calculations that happen to look identical today but represent genuinely independent business rules can, and often will, need to diverge later; forcing them into one shared abstraction prematurely creates exactly the kind of awkward, overly-general code that's harder to maintain than the original 'duplication' would have been. Another frequent error is assuming DRY means minimizing total lines of code — DRY is specifically about avoiding duplicated KNOWLEDGE (a fact or rule with a single source of truth), not about code brevity for its own sake; a longer, clearer implementation with zero duplicated knowledge is more DRY-compliant than a shorter one that duplicates a business rule in two places.
✓ Quick Self-Test
Can you explain, using a concrete example, why duplicated business logic creates a maintenance risk beyond just 'more typing'? Given two pieces of similar-looking code, can you correctly reason about whether they represent genuinely duplicated knowledge (a real DRY violation) or coincidentally similar code that may reasonably diverge over time?
Next Lesson
Complexity Trade-offs
→
← All Programming Concepts Lessons