Principles misapplied: Is WET really that bad?

What is DRY and WET again?

"Don't Repeat Yourself" and "Write Everything Twice" are essentially the same principle. One instructs you what to do, while the other tells you what not to.

The principle states that we should not have duplicate code in our software. Duplication means that when we need to make a change, we have to make it in all the duplicated code, thus increasing the amount of work and the cognitive load.

Moreover, humans are forgetful. So it is only a matter of time before someone forgets to propagate the change to all duplicated code, resulting in unexpected errors.

This effect is further amplified when we factor in unit tests. Duplicate code means duplicate tests, thus increasing maintenance costs even more.

Should you strive for a completely DRY codebase

After reading the explanation above you might conclude that 100% DRY code would be the best. But alas, the sweet spot is found somewhere between DRY and WET code.

Though many developer might be aghast that I even suggest to write some stuff twice, let’s look at what happens when we take the DRY principle too far.

Given the following example

You might rightfully decide that this is duplicated code and should be refactored. So you create a PriceTransformer class with a GetDisplayPrice method and call it a day:

But now the fun part begins. The next day someone from the store department complains that the store is displaying more than two decimals. You decide to simply fix this by rounding the input to two decimal places.

However, now the purchasing department is complaining. Those decimals might not be important for the store, but when purchasing bulk items they do influence the final price.

You solve this by adding a new parameter called shouldRound and end up with

Satisfied, you close down for the day and all seems to be well.

But new feature requests come in over time and more and more logic sneaks into your beautiful DRY code:

After a couple of more sprints, your clean abstraction turned into a huge amalgamation of if-statements and switch statements that nobody wants to touch anymore. Your team's velocity plummets, the code quality reaches all-time lows, and a colleague hands you a copy of Clean Code subtly opened to the chapter about the Single-Responsibility principle.

While the above example is somewhat extreme, this does happen all the time. You reference an already existing service because it does exactly what you need or you reuse a query that someone already wrote.

This is where spaghetti code happens; you're removing the wrong duplication.

Incidental duplication should stick around

The examples above are what we call incidental duplication.

At first glance, the formatting of a product price across different services may look very similar or even identical. However, upon closer inspection, you will find that the code represents different behaviors in your application.

Incidental duplication does not duplicate behavior, domain knowledge or other concepts, yet still looks (exactly) the same.

When refactoring incidental duplication, you get the opposite of what the DRY principle tries to achieve. Your code becomes difficult to understand and daunting to change. You end up with spaghetti code because suddenly different domains are coupled through shared code, even when they do not share any real-world similarities.

A mnemonic of three

I often keep this quote in mind when I encounter suspicious duplication: You might have already encountered it as the Rule of Three. This rule is a good guideline to prevent identifying incidental duplication as actual duplication.

By waiting for a third duplication to occur, you give yourself the chance to see whether the represented concepts really are the same. You will also have more information about the requirements, similarities and differences, allowing you to create a better abstraction instead.

Even though the rule says that you should refactor the moment you write something for a third time, I would suggest waiting until you are absolutely certain you have all the information to make the right decisions. Sometimes, you will have to wait for a fourth or fifth duplication before you know the best course of action.

A note of caution

As developers, we learn plenty of rules, heuristics, guidelines, and principles. We discussed how harmful the DRY principle can be if it is over-applied. But along the way, I introduced yet another rule, the Rule of Three.

As with the DRY principle, you shouldn't take this rule too seriously. All these rules are just different ways to reason about the decisions we have to make. In the end, you, the developer, will have to pick the best possible solution.

If you take away only one thing from this article, let it be this: while best practices are well-established for a reason, don't just follow them blindly. Use them when it makes sense.

Finally

You will find yourself in situations where you aren’t sure whether something is incidental or actual duplication. In that case I advice: just push the duplication and refactor it later or await the feedback in the pull request. I personally would always prefer one simple duplication too many than a bad abstraction.

Also, if you find yourself (like me) calling it accidental duplication instead of incidental, rest assured that it means virtually the same. Mariam Webster tells us that:

Accidental and incidental can both mean "something happening by chance," but usage suggests that "accidental" also implies an element of carelessness or inattention while "incidental" implies the occurrence would have happened with or without attention or care