DRY vs. WET


DRY (Don’t Repeat Yourself) is a long-standing rule of thumb for good software architecture. Duplicate code leads to unexpected divergences in behavior over time, makes it harder to refactor, and creates extra work. But it can be misapplied. It’s tempting to write code in anticipation of future duplication, especially for someone fresh off of learning about design patterns, but premature abstraction can waste more time than it saves. Abstraction isn’t free: Every extra layer makes it harder to see and reason about what exactly is going on in the code. Even code that needed to be abstracted might have been structured in a way that’s hard to re-use in practice. DRY applies to duplicate code but not necessarily to code that merely rhymes.

WET (Write Everything Twice) adds nuance to the concept of DRY. You can’t know which exact code will be duplicated until you’ve written it out more than once. You can’t know which exact parts will be duplicated and which will be unique until you have multiple implementations that can be compared and contrasted. You might find that the seemingly duplicate code should have diverged into separate implementations and that you have to tear them back apart anyways. And, given the level of abstraction that most code is written at today, most programmers deal with far less duplication than even a decade or two ago. DRY is a good rule of thumb but patience and WET will produce the most sustainable results.

If you do something once, then you’re done and you can stop. If you do something twice then you may see ways to improve upon your process. When you start on that third go-around, though, that’s when you have a pattern of behavior worth optimizing. Where else, besides code, can you apply WET and DRY to your life?