DRY Principle

Reference: The Pragmatic Programmer (Hunt & Thomas), Tidy First? (Beck), Software Engineering at Google (Winters et al.)

When to Apply

• Evaluating whether two similar code blocks should be extracted into a shared abstraction
• Reviewing code for duplicated business rules, logic, or knowledge
• Deciding whether an existing abstraction is the right one or should be reverted to duplication
• Refactoring a codebase with repeated logic that has begun to diverge
• Assessing whether a shared library or utility is worth the coupling cost

What DRY Actually Means

The formal definition from Hunt & Thomas (1999): "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."

DRY is about knowledge duplication, not code duplication. Two identical-looking code blocks that represent different business concepts are NOT a DRY violation. Two different-looking code blocks that encode the same business rule ARE a violation.

The Acid Test

"If this business rule changes, would ALL of these locations need to change in exactly the same way?"

• If yes → true DRY violation — extract a single authoritative representation
• If no → incidental similarity — leave them separate; they will likely diverge

Five Types of Duplication

• MUST eliminate knowledge/logic duplication — this is the most dangerous form
• SHOULD eliminate code duplication only after confirming it represents the same knowledge
• SHOULD use shared schemas or code generation to reduce representation duplication across boundaries

When DRY Becomes Harmful

The Wrong Abstraction (Metz)

"Duplication is far cheaper than the wrong abstraction."

The pattern that leads to the wrong abstraction:

1. Developer sees duplication and extracts it into a shared abstraction
2. New requirement is almost the same — add a parameter and conditional
3. Repeat step 2 several times
4. The abstraction becomes an incomprehensible tangle of conditionals
5. Sunk cost fallacy prevents reverting: "We already built this; let's just add one more parameter"

The remedy: The fastest way forward is back. Re-introduce duplication, then re-abstract based on the actual patterns that emerge.

Coupling Cost

Every extraction creates a dependency. Extracting a shared utility between two services couples them — changes to the utility require coordinating both services.

• MUST weigh the coupling cost of extraction against the maintenance cost of duplication
• Duplication between independently deployed services is often the right choice
• SHOULD prefer duplication over coupling across team or service boundaries (Winters et al., Software Engineering at Google)

Rule of Three

Don Roberts, popularized by Fowler: "The first time you do something, just do it. The second time, wince at the duplication but do it anyway. The third time, refactor."

With only two examples, you cannot reliably identify the true pattern. By three, the commonalities become visible and the abstraction has a solid foundation.

Rules

• MUST NOT extract a shared abstraction on the first occurrence
• SHOULD tolerate duplication on the second occurrence, noting it for future refactoring
• SHOULD extract on the third occurrence, when the true pattern is clear
• MUST verify that all three instances represent the same knowledge before extracting

AHA Programming

"Avoid Hasty Abstractions" — coined by Kent C. Dodds (2020): "I'm fine with code duplication until you feel pretty confident that you know the use cases. At that point, the commonalities will 'scream at you for abstraction.'"

AHA is the synthesis of DRY and WET ("Write Everything Twice"):

• SHOULD optimize for change first — future requirements are unknown
• SHOULD abstract when you are confident about the use cases, not before
• SHOULD NOT set a fixed numeric threshold — the right moment depends on how well you understand the pattern

Decision Framework

When you encounter similar code, follow this sequence:

1. Is it the same knowledge? Apply the acid test. If different business rules happen to look similar, stop — leave them separate.
2. How many occurrences? If fewer than three, tolerate the duplication. Note it with a comment if helpful.
3. What's the coupling cost? If extraction creates a dependency across service, team, or deployment boundaries, prefer duplication.
4. Is the abstraction clear? If you can name the extracted concept and it represents a single, stable piece of knowledge, extract it. If the name is vague (CommonUtils.processData) or requires parameters to handle divergent cases, the abstraction is wrong.
5. Can you undo it? If the extraction turns out to be wrong, you must be willing to re-inline. Sunk cost is not a reason to keep a bad abstraction.

Common Pitfalls

Checklist

When evaluating duplication, verify:

• The acid test confirms this is knowledge duplication, not incidental code similarity
• Three or more occurrences exist (Rule of Three) — or the pattern is unmistakably clear
• The extracted abstraction has a clear, specific name representing one concept
• No boolean flags or type-switching parameters are needed to handle different use cases
• The coupling cost of extraction does not exceed the maintenance cost of duplication
• Cross-boundary duplication is preferred over cross-boundary coupling
• Existing wrong abstractions have been identified and considered for re-inlining
• Tests remain readable — test duplication is acceptable for clarity

Key References

Online References

• Sandi Metz, "The Wrong Abstraction" (blog post, 2016)
• Kent C. Dodds, "AHA Programming" (blog post, 2020)