Do Repeat Yourself

There is a place for duplicated code, after all.

Welcome to another edition of “Station Wagon Full of Tapes”. In this article I am practically complaining about the increasing obsessiveness on keeping the code DRY and why I like to sometimes duplicate code, on purpose.

One of the holy principles of programming seems to be “Don’t repeat yourself”. I, for one, did not learn or hear about this before I was part of the industry. I know who coined the term. I know that they are well-skilled software engineers. However, I am sensing a trend where the idea behind itself has been through the DRY filter, and became a lesser, “simpler” version of itself. Which is all duplicate code is evil, please avoid at all costs.

Today, one of the most common code review comments I notice is “do you think we can abstract this section out to a function and re-use?”. I, for one, also tend to give this feedback during reviews from time to time. 

There are trends in software engineering — as with anything. This specific trend about the journey of DRY code is not new, however it became more and more only about duplicated code. It is in a way gamified, the satisfaction of creating another helper method to do one thing in multiple places.

Recently, I had a change of heart. Mostly because I am now part of a team that had to take over some “old” (it really isn’t that old) code and had to retrofit it to a scalable future. The code contained re-usable utilities that were only re-used for two (2) times in total. When the utility was created it did in fact avoid duplication of code. The logic that was moved to a function that had single responsibility. Time passed by, re-orgs happened, some unknown unknowns occurred, unit testing coverage needed to increase. The function now was still only used in two locations, however had so many logical branching (if statements) to accommodate the two it became a hard one to understand. Which sources my frustration with the DRY approach now. 

I see many examples of moving duplicated sections into common functions, however, I rarely see a code change the other way around. The single responsibility function gets more and more complicated. Instead, what if we applied some moisturizer to the dryness and moved the function back to duplicated versions. 

To be able to enable this new architecture and structure I’ve mentioned above; I was trying to reorganize the existing code and modules. Fighting with dependency cycles, trying to create some more utilities to abstract sections out. I was not moving forward but just circling around. 

Things have changed when I just started copy-pasting sections of code to each module that actually used it, and then making them private to that module only. The code became easier to follow, easier to reason, easier to test. What better value to a scalable code than it having the aforementioned attributes. It was not a beautifully structured code (can a code be beautiful?), at least not in the 2021 DRY standards that every engineer keeps pushing towards each other. But it works, and I guarantee you that it is more flexible than it ever was for future changes, for the next engineer assigned to work on it after another team shuffling at a company.

Thank you for reading “Station Wagon Full of Tapes”.