{"post":{"slug":"dry-vs-wet-code-2026","title":"DRY vs WET Code in 2026: When to Repeat Yourself","excerpt":"DRY tells you not to repeat yourself, but duplication is sometimes the safer choice. Here is how to tell a real DRY violation from two blocks of code that just look alike.","category":"code","date":"July 1, 2026","author":"ByteLedger Team","content":"<span class=\"dropcap\">D</span>RY — \"do not repeat yourself\" — is one of the most quoted principles in software engineering, and one of the most frequently misapplied. WET is the tongue-in-cheek counterpart, commonly expanded as \"write everything twice.\" The honest answer is that both principles are right in different situations, and treating DRY as an absolute rule is how codebases end up with abstractions nobody can safely change.\n\n## What changed in 2026\n\n- AI pair programmers made it trivially cheap to generate near-duplicate code fast, which increased the temptation to over-abstract early just because an assistant offered to \"extract this into a shared function.\"\n- \"Rule of three\" thinking (duplicate twice is fine, abstract on the third occurrence) became the dominant guidance, replacing reflexive DRY-on-first-repeat habits from earlier style guides.\n- Feature-flag-heavy codebases pushed teams toward accepting more duplication deliberately, since a shared abstraction touched by multiple flags becomes a coordination bottleneck.\n\n## What DRY actually means\n\nThe DRY principle, as originally stated, is about knowledge duplication, not text duplication. Two functions that happen to have similar-looking code but represent different business rules are not a DRY violation, even if the code looks nearly identical. A DRY violation is when the same piece of business knowledge — a tax rate, a validation rule, a pricing formula — is expressed in more than one place, so that changing the rule requires remembering to update every copy.\n\n## What WET code looks like\n\nWET code repeats the same logic across the codebase with no shared source of truth. It is easy to write, easy to read in isolation, and easy to modify locally without breaking anything else. Its downside shows up later: a bug fix or rule change has to be applied in every duplicated location, and it is easy to miss one.\n\n## DRY vs WET: the tradeoff\n\n| Factor | DRY (abstracted) | WET (duplicated) |\n| --- | --- | --- |\n| Change cost when logic updates | Low - change one place | High - must find and update every copy |\n| Risk of divergence/inconsistency | Low | High |\n| Coupling between unrelated features | Higher - shared code creates shared risk | Lower - each copy can evolve independently |\n| Readability in isolation | Lower - logic is indirect, behind an abstraction | Higher - everything needed is visible in one place |\n| Best when | The duplicated logic represents one true business rule | The similarity is coincidental, or requirements are still shifting |\n\n## When to abstract, and when to wait\n\nDuplication is not automatically bad; premature abstraction is often worse than duplication, because the wrong abstraction is expensive to unwind once several features depend on it. A practical rule: tolerate duplication the first and second time you see a pattern. On the third occurrence, evaluate whether the three instances truly represent the same rule — if they do, extract a shared function; if they only look similar today but are likely to diverge, keep them separate.\n\n## Common mistakes\n\n- **Abstracting two coincidentally similar blocks of code** that represent unrelated business rules, creating a shared function that has to grow branches and flags to handle both cases as they diverge.\n- **Chasing DRY across unrelated modules** just because a linter or an AI suggestion flagged similar-looking lines, ignoring whether the similarity is meaningful.\n- **Under-abstracting genuine duplication** of a real business rule, such as a tax calculation copy-pasted into five places, so that a rule change requires a five-location hunt-and-fix.\n- **Confusing DRY with shortness.** A one-line helper that saves three lines of typing but obscures what is happening is not a DRY win if it makes the code harder to follow.\n\n## FAQ\n\n**Is DRY the same as writing shorter code?**\nNo. DRY is about eliminating duplicate knowledge, not duplicate characters. A verbose but clear function can be perfectly DRY; a terse one-liner reused everywhere can still be a bad abstraction if it forces unrelated callers to share behavior they should not share.\n\n**What is the rule of three?**\nA guideline that says duplication is acceptable the first two times a pattern appears. Only on the third occurrence should you seriously consider extracting a shared abstraction, since by then the pattern is more clearly a real, recurring rule rather than a coincidence.\n\n**Does DRY apply to test code the same way it applies to production code?**\nMostly no. Tests often benefit from being WET and explicit, because a shared test helper that changes behavior across many tests can hide the actual assertion being made, making failures harder to diagnose.\n\n**How does this relate to design patterns like factory or singleton?**\nDesign patterns are structured ways to share behavior once you have decided abstraction is warranted. See the [factory pattern explained](/blog/factory-pattern-explained-2026) guide for one common approach to sharing object-creation logic without over-coupling callers.\n\n## Where to go next\n\n- [Design patterns: singleton explained in 2026](/blog/design-patterns-singleton-explained-2026)\n- [Factory pattern explained in 2026](/blog/factory-pattern-explained-2026)\n- [Type safety explained in 2026](/blog/type-safety-explained-2026)","hue":320,"metaTitle":"DRY vs WET Code Explained 2026","metaDescription":"DRY vs WET code in 2026: why avoiding repetition is not always right, when duplication is safer than a bad abstraction, and how to tell the difference.","keywords":["dry vs wet code 2026","dont repeat yourself principle","wet code meaning","premature abstraction","code duplication tradeoffs","when to refactor duplication","dry principle explained","software design principles","rule of three refactoring"],"tldr":["**DRY is about duplicate knowledge, not duplicate text** — two similar-looking blocks are not a violation if they represent different rules.","**Premature abstraction is often worse than duplication** — the wrong abstraction is expensive to unwind once several features depend on it.","**The rule of three is a practical guideline** — tolerate duplication twice, evaluate extraction on the third occurrence.","**WET code trades update cost for local readability** — every copy has to be found and changed by hand when the rule changes.","**Skip:** abstracting two coincidentally similar blocks of code just because a linter flagged them — check whether the similarity is meaningful first."],"readTime":"4 min read","wordCount":837},"related":[{"slug":"how-to-write-clean-functions-2026","title":"How to write clean functions in 2026","excerpt":"Clean functions are the single highest-leverage thing you can do for code quality. Here is the 2026 playbook with concrete rules and real examples.","category":"code","date":"March 18, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":318},{"slug":"solid-principles-explained-2026","title":"SOLID principles explained in 2026: five rules for better code","excerpt":"SOLID is five design principles for object-oriented code, from single responsibility to dependency inversion. Here is what each one means and when to skip them.","category":"code","date":"July 16, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":290},{"slug":"what-is-the-single-responsibility-principle-2026","title":"What is the single responsibility principle in 2026?","excerpt":"The single responsibility principle says a class or module should have one reason to change. Here is what that means in practice and where it gets misapplied.","category":"code","date":"July 24, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":280}],"sameCategory":[{"slug":"bazel-build-explained-2026","title":"Bazel Explained: What Hermetic Builds Actually Cost","excerpt":"Bazel delivers reproducible, precisely cached builds and demands that you describe everything. Here is what you get, what it costs, and who should say no.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":145},{"slug":"graphql-federation-2026","title":"GraphQL Federation: One Graph, Many Teams","excerpt":"Federation composes independently-owned subgraphs into a single API. Here is what it solves, the operational cost it adds, and when a simpler gateway is enough.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":300},{"slug":"hermetic-builds-explained-2026","title":"Hermetic Builds Explained: Same Inputs, Same Output","excerpt":"A hermetic build depends only on declared inputs. Here is what that property gives you, the common leaks that break it, and how to move toward it incrementally.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":130},{"slug":"monorepo-tooling-compared-2026","title":"Monorepo Tooling Compared: What You Actually Need","excerpt":"Monorepo tools solve task orchestration and caching, not repository layout. Here is what each tier provides and how to tell when you have outgrown the simple option.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":150}],"newer":{"slug":"domain-driven-design-basics-2026","title":"Domain-Driven Design Basics for 2026: A Practical Primer","excerpt":"A plain-language introduction to domain-driven design in 2026 — bounded contexts, ubiquitous language, and when the pattern earns its complexity.","category":"code","date":"July 1, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":200},"older":{"slug":"edge-computing-explained-2026","title":"Edge Computing Explained in 2026: Why It Matters Now","excerpt":"Edge computing moves processing closer to where data is generated instead of sending everything to a distant data center. Here is why that matters more in 2026 and where it is used.","category":"tech","date":"July 1, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":305}}