Don't DRY Your Code Prematurely

Original Article ↗ Hacker News Discussion ↗

Engineers debate the “Don’t Repeat Yourself” (DRY) principle, arguing that aggressively eliminating duplication can create brittle abstractions that are harder to change than straightforward, repeated code. Many advocate delaying DRY until patterns and business rules are clearly understood (e.g., “rule of three,” WET/AHA/SPOT), prioritizing readability and single sources of truth for actual domain knowledge rather than superficial code similarity. The consensus trend is that duplication is often cheaper and safer early on, while over‑generalized shared code can entangle unrelated behaviors and make maintenance and debugging significantly more difficult.

What DRY Is (and Isn’t)

  • Many argue DRY is about de-duplicating knowledge or “sources of truth,” not just identical-looking code.
  • A key test: if a single business rule changes, should you only have to change it in one place? If not, you’re violating DRY.
  • Others frame this as SPOT (Single Point of Truth) and DAMP (“Don’t Alter in Many Places”).

Premature Abstraction, WET, and the Rule of Three

  • Strong theme: premature abstraction is more dangerous than initial duplication.
  • Several endorse “Write Everything Twice” or “Rule of Three”: only extract an abstraction after seeing the pattern recur and stabilize.
  • Copy‑pasting early is seen as a valid technique to let real differences emerge before coupling things.

When Over‑DRY Backfires

  • Common complaints:
    • God functions/classes with many flags and conditionals.
    • Deep, indirect call chains where simple changes require understanding many layers.
    • Hard‑to‑debug generalized pipelines, metaprogramming, and over‑generic TypeScript types.
  • Undoing a bad abstraction is often described as harder than consolidating duplication later.

When Under‑DRY Hurts

  • Others report the opposite pain:
    • Same 20–30 lines copied dozens of times; bug fixes must be hunted and patched everywhere.
    • SQL queries, logging, validation, encoders/decoders and other “must stay consistent” logic are cited as things that should be centralized.
  • Lack of DRY is framed as technical debt; some insist “not drying is technical debt by definition.”

Readability, Maintainability, and Tests

  • Many prioritize readability and ease of change over strict DRY or minimal LOC.
  • DRY is defended as a maintenance tool: fewer places to update, fewer inconsistency bugs.
  • Tests are seen as the safety net that makes both refactoring to DRY and “wetting” abstractions feasible.

Critiques of the Google Example and Guidance

  • The blog’s DeadlineSetter example is widely viewed as a weak or straw‑man abstraction; simpler functions would illustrate the tradeoff better.
  • Several note the post repeats older, better explanations of “wrong abstraction” without adding much nuance.
  • Broad consensus: DRY is useful, but only when guided by domain knowledge, real change history, and judgment—not as a universal rule.