Don't DRY Your Code Prematurely

Original Article ↗ Hacker News Discussion ↗

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.