Applying DRY can make you WET

Introduction

We live in a world overwhelmed by information at the tip of our fingers. This is extremely valuable if you have the discipline to study everything with care and consistency, but sometimes we just rush it.

We’ve all heard of the famous DRY (don’t repeat yourself) principle over and over again, and there are countless articles on this topic, but most of them seem to lack something that I find very important — DRY is not an order from the Gods to remove every single duplication, it is the Uncle Bob on your shoulder reminding you to take care of your code and make sure that you understand the problem that you are solving. This is a principle that many take too seriously and literally, which counter intuitively causes much more pain than relieve. Yes, I know that until this moment in the article everything is still very abstract, but stay with me and I promise that I will try to explain everything.

Agenda

We are going to study DRY by answering to main questions:
1. What is the DRY principle?
2. How can DRY make you WET, and what does WET mean?

DRY Explained:

To understand it, we should first understand what is our job as Software Developers. What do we do? Yes, we solve problems, but not just any problems. We are paid money in exchange of our time and knowledge to translate business process into code. Our duty is to take a process that generates money and make it easier, faster, more intuitive, automated, less error prone (by proper design decisions) by translating it to the machine in a language that it understands. So, we are not valuable just because we sit and solve problems, we are valuable because we solve the right kind of problems for the right kind of people. Our efforts yield a product that will ultimately (and hopefully) be more productive than the manual execution of the business tasks.

The ones of you familiar with SOLID can see that with the explanation above, I am inferring SRP (Single Responsibility Principle), which places your code into context, giving it a special meaning when read and used in it. DDD (Domain Driven Design) can expand your view on the contexts in code, but I want to point single thing out — as the same as two words that have different meanings in different context, code can have different meaning in different context. This means that you shouldn’t remove duplication just because two parts of the code look alike. You can have two methods with very similar structure and syntax serving two totally different purposes. This difference won’t reveal itself to a reader that is not familiar with the context of the code, or with the business problem. The general advice is to think twice before extracting a new method, and if not sure — wait before acting too fast.

Not complying with DRY leads to business logic leaking throughout the code base, leading to maintenance hell with time; it is a violation of SRP and OCP (open/closed principle), and all of this leads to big impact of small changes. DRY boils down to carefully extract common functionality by making the conscious decision to do it, by knowing the problem, and knowing the context.

DRY making you WET?

I’ve stumbled upon different meanings of WET (Write Everything Twice; Waste Everybody’s Time), but I like to view it as “Wasn’t Expecting That” as in like “Sorry, wasn’t expecting that”. Why such a dramatic sentence? Because not doing DRY right you can inflict damage as bad as not doing it. How is this possible? Easy, eliminating duplication without thinking about it carefully can lead to a very tight coupling of business logic that appears to be the same at first sight, but serves two totally different purposes. Yes, you will have less code, but at a very high price. Extracting code from several contexts into a single method will look beautiful and good idea at first, but with time the different purposes will try to come to the surface, and you can recognize this by the emerging branching logic inside of the method, trying to break out the context depending on the situation. Sooner or later the if/else or switch statements will grow making code very hard to reason about, to reuse, and to change. You will find yourself having a very bad time “stuffing” code in this single method just because you missed the tells at the beginning. This will be a method having “Dissociative identity disorder”, as I call it. And where does WET fit? Right here — all of this will lead to very big ETAs for simple requests, and sometimes even more time than you anticipated leading to “Sorry, wasn’t expecting that” message in the chat.

Thank you!

Thank you for reading my first article, which I really enjoyed putting together in the middle of the night. I would really like to hear your feedback on it. Would you like to dive in another article together with me (if yes — on what topic), or you want me to shut up :D? Best of luck and happy knowledge hunting.