Should we always keep it DRY?

I am not talking about my basement, if I was the answer is a resounding YES! which I why I am having a waterproofing come up to the house to patch a hole in the foundation.

DRY in this case is an acronym for Don't Repeat Yourself.  This first place that I read about this principle was in The Pragmatic Programmer by Andrew Hunt and David Thomas, as far as I am aware they are the ones that made up the acronym DRY. In their words "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." The goal is to avoid having multiple copies of code that diverge from each other, thereby causing bugs when a change is not applied to all copies.

As with all software development principles, it is important to ensure that we correctly apply this principle. As developers we need to be careful not to create duplicate code as this is, of course, undesirable. At the same time we need to make sure that we do not violate any architectural principles and we also need to be certain that we are looking at actual and not apparent duplication. At this point you may be wondering if I have lost my mind, isn't it fairly obvious if there are 2 methods in the same object of same hierarchy that have identical code. Yes that is obvious and today there are tools that will help us find and remove duplicated code. I am concerned that we remove the duplication in a way that doesn't decrease readability, that doesn't violate architectural design and that it is actual duplication.

I have seen too many developers, who apparently have had the DRY principle driven into their brains apply this relentlessly. In one case small sections of functions had between 2 and 4 lines of duplicated code across modules and architectural boundaries. The "fix" put in made the code significantly harder to read, (bad choices for method names didn't help) and added complexity to the code. Worse was not noting the architectural boundaries, the "fix" added a dependency between modules in the wrong direction across an architectural boundary. It is critical that we manage component and architectural dependencies. (This cannot be overstated and here I leave it as a single line in a blog...left an as exercise to the reader to understand why.)

Lastly, I mentioned apparent duplication. This happens much more often with data structures then method bodies. In apparent, but not real, duplication the two structures are logically separate and exist for separate reasons. Combining them will reduce maintainability because it will add dependencies. In most cases these structures will diverge due to feature requests. If they are forced together into the same structure then all interactions with that data structure will, over time, will not use all fields. One could argue force them together now and refactor later, based on architectural design that may or may not be appropriate. 

In short I just wanted to point out that relentless de-duplication is great as long as we keep in mind the larger architectural concerns of the software.