Refactor not DRY: why we are not afraid of code duplication

The DRY (Don’t Repeat Yourself) principle is one of the cornerstones of the modern software development and the crucial part of refactoring. Unfortunately, many developers get it completely wrong.

When a new software project goes on, the codebase grows significantly over time, as the new features are added. In order to ensure maximum usability and transparency of the code, it is refactored to comply with the requirement of having the absolute minimum of functions and values needed to run it. This seems to fall in the line with the DRY principle:

“Every knowledge piece must have a single unambiguous, authoritative representation within a system.”

Note, however, that this definition does not say anything about code, even though being related specifically to the software development. It is all about KNOWLEDGE, meaning the use cases, the functions, the algorithms — not the lines of code. This makes all the difference in the world in our eyes.

We do agree that excessive duplication is unnecessary — yet we stand firm that early refactoring is rather harmful, not helpful. Even if the logic of 2 pieces of code is similar, the results they should produce are quite rarely the same, so they should not be combined. As a matter of fact, unnecessary standardization of code almost always leads to poor handling of edge cases, bad code readability or overall performance issues.

Quite the contrary, having multiple similar (yet not same) pieces of code allows for greater flexibility and provides a greater field for maneuver when the development goes on. As the codebase grows and the developers add more depth to the product features, the cases where refactoring is needed will emerge on their own, while the cases where DRYing is rather harmful will also present themselves.

This is why at IT Svit we do not emphasize the early refactoring as a rule of thumb. For example, if a project requires 400 man/hours only, devoting 50 hours to the code DRYing is obviously redundant. We refactor the code to ensure it runs well under any conditions, performs all the required functions and is modular enough to permit simple upgrades when needed. Even if there are several duplicating pieces of code we leave them be and just make sure they perform varying functions.

Final thoughts on why IT Svit does not favor DRY over functionality

Following this paradigm ensures we provide functional and clean code under budget and on time. As IT Svit is one of the top 15 managed services providers worldwide (and one of the leading IT outsourcing companies in Ukraine according to Clutch), we quite often get to support and maintain the websites and apps we develop.

Thus said, it is in our best interests to provide high-quality products, as it will be our responsibility to ensure their stable performance in production. This is why we do favor functionality over DRYing and are not afraid of code duplication when it is needed.

What’s your opinion on the topic? Did you have an experience of too intense refactoring? Please share your thoughts in the comments below, and if you need a sound project to be developed and delivered on time — contact IT Svit team, we will be glad to assist!