The DRY principle — Don't Repeat Yourself, from Andy Hunt and Dave Thomas's The Pragmatic Programmer, discussed in more detail elsewhere on this shelf — states that every piece of knowledge should have a single, unambiguous, authoritative representation within a system. The principle is frequently summarized more loosely as “don't duplicate code,” which is a narrower and less accurate reading than the original formulation, and that narrowing is responsible for a lot of the principle's real-world misapplication. Background on the original principle appears in this DRY principle overview.
The difference between duplicated knowledge and duplicated code
The original DRY principle is about knowledge, not about surface-level code similarity. Two pieces of code that happen to look similar today, but represent genuinely different business rules that could reasonably change independently in the future, aren't duplicated knowledge — they're a coincidental resemblance, and unifying them creates an incorrect coupling where none should exist: a future change to one rule now risks silently breaking the other, unrelated rule, purely because someone earlier merged them for looking alike. Documentation and tools often act as external memory; this reference explains the related idea of cognitive offloading.
This distinction — sometimes summarized with the counter-term WET (loosely, “write everything twice,” or “we enjoy typing”, used somewhat tongue-in-cheek) — argues that a small amount of genuine duplication is often a better trade than a premature, incorrect abstraction, because duplicated code is at least easy to understand and easy to later unify correctly once the real relationship between the two pieces becomes clear, while an incorrect abstraction actively obscures that relationship and is often harder to safely undo than the original duplication would have been to simply tolerate.
The rule of three, and why it's a heuristic, not a law
A commonly cited heuristic — sometimes called the rule of three — suggests waiting until a piece of logic has been duplicated three times before extracting a shared abstraction, on the theory that two instances aren't enough evidence to know whether the similarity is a real, stable relationship or coincidental. This is a reasonable default rather than a strict law: some duplication is obviously the same knowledge from the first instance (a tax rate used in two places is clearly one fact, not two), and waiting for a third occurrence in that case just delays an obviously correct fix. The heuristic is most useful specifically in the ambiguous cases, where it's genuinely unclear yet whether two similar-looking pieces of code represent one concept or two.
- Ask whether duplicated code represents genuinely the same piece of knowledge, not just similar-looking syntax — that distinction determines whether unifying it is correct or premature.
- An incorrect abstraction is often more expensive to undo than tolerated duplication — when genuinely unsure, duplication is usually the safer default until the real relationship is clear.
- The rule of three is a heuristic for ambiguous cases, not a rule for obviously-shared facts (like a single tax rate or a single configuration value), which should be unified immediately regardless of how many times they've appeared.
- Revisit early abstraction decisions as more instances appear — a shared function that was correct for two similar cases can become the wrong shape once a genuinely different third case arrives.
Why this connects to the smells and technical-debt guides on this shelf
An incorrect, premature abstraction is itself a recognizable code smell, discussed elsewhere on this shelf, and unwinding one later is a specific, common form of the technical debt also discussed on this shelf — debt that was taken on with good intentions (following DRY) but without enough evidence yet to know whether the abstraction was actually correct. Recognizing this pattern early — an abstraction built from only two data points, forced awkwardly to accommodate a third — is one of the more common, specific signals that it's worth revisiting rather than extending further.
Applied with that distinction in mind, DRY and its counterpoint WET aren't actually in conflict — they're both pointing at the same underlying judgment call, from opposite directions, about when similarity reflects a real shared concept and when it doesn't.