102. Whether or Not to Repeat Yourself: DRY, DAMP, or WET

Robert Blumen is a DevOps Engineer at Salesforce, joined by Ev Haus, Head of Technology at ZenHub. Together, they're going over a critique over several methodologies when writing code as part of a large team. First, there's DRY, which stands for Don't Repeat Yourself. It's the idea that one should avoid copy-pasting or duplicating lines of could, in favor of abstracting as much repeated functionality as possible. Then, there's DAMP, or Don't Abstract Methods Prematurely, which is somewhat in opposition to DRY. It advises teams to not create abstractions unless they are absolutely necessary. Last on the list is WET, or Write Everything Twice. This is the idea to embrace duplication whenever possible.

Ev notes that, like many programming absolutes, the success of each strategy depends entirely on the context. DRY, for example, sounds like a really good idea, until it happens everywhere. Suddenly, a chunk of code becomes difficult to reason, as a developer jumps around various method definitions to piece together a flow. DAMP often makes sense as a counterpart to DRY, because if you abstract too early in your codebase, you may find yourself overloading methods or appending arguments to handle one-off cases. DRY is typically best suited for testing environments, where an absolutely reproducible set of explicit steps is often preferable in order to quickly understand what is occurring.

No matter the strategy you use, the core tenant is to solve the problem first. Try to accomplish the goal you need to, whether that's adding a feature or squashing a bug. Don't over optimize until you've finished what you need to, and don't think too far into the future about all the possible edge cases. The rest of the balance comes with experience. Some duplication is bad, but not all of it. Figuring out the absolute perfect solution is unlikely, so you've got to put the code out into the real world to find out what works. After that, bake some flexibility into your processes to adjust hot code paths or refactor them when needed!

Links from this episode

• ZenHub is an agile project management tool for GitHub
• Wikipedia's definition of DRY
• "Using DRY, WET & DAMP code" is Ev's article on different coding methodologies
• Codewars is a website with programming puzzles and challenges
• The Pragmatic Programmer by Dave Thomas is a popular book highlighting some of these concepts
• DRY code, DAMP DSLs by Jay Fields and DRY vs DAMP in Unit Tests by Vladimir Khorikov are more write-ups on the subject