Redundancy. Repeating yourself. Duplication. Copy-paste.

These have become like curse words in IT. This data is completely redundant! Did you just copy-paste that code?

We all learn early on in our programming ventures about how code duplication is bad. It creates maintenance nightmares we are told. Our code should be DRY. I believed it and lived by it. But as I am maturing in my programming I am more and more starting to doubt it.

The problem with dry code is that it’s very easy to start overdoing it. I mean what is code, but the basic instruction set repeated over and over again with some slight variations? Ever wrote a for loop?

for (int i=0; i<myList.length; i++) {
// Ah looping over a list... total deja vu!
}

Seen one seem em all right? The nature of programming seems to lead us to reuse the same solutions for the same kinds of problems all the time. It kinda feels wrong. We should probably try to reuse that code. So we build utility functions, tools classes, common libs and what not. And it ends up hurting us. Our projects somehow all seem to become intertwined with one another. Our loose coupling is lost.

Again and again I’ve found myself having to choose: duplicate a class from one project or package into the next, or create a dependency on a whole bunch of classes when really I only needed one. Lately, I tend to lean more and more towards old-fashioned copy-paste.

Of course one could argue that when that specific class is needed and not the rest of the package, it’s a sign that things have been put together that don’t belong together and that some refactoring is in order. Although right and pure, this has the very practical problem that, apart from being a lot of work, refactoring an otherwise stable project entails a considerable risk. And for what really? So a bug gets found in class A and that was at one time copied from some other project. So now we have to fix it in two places. Or even three. How bad is that really? Would it be bad enough to counteract the advantages of only adding a single class to a project instead of a dozen or so? What if one of those other classes from that other project has a bug? What if fixing that bug requires changes to the class my project is using from that other project which introduce bugs in my project?

Dependencies, dependencies. They can be a real pain. Dependency hell is what they call it. It seems to me that when I try to prevent dependency hell, I am inviting repetition in my code. But when I try to prevent repetition, I am encouraging dependency hell. Seems we have to make a choose between DRY and loose coupling. More and more I am thinking: I like my code wet.

What do you think? Can we have the cake and eat it too? Minimize repetition and still have loose coupling and steering clear of dependency hell? Please share your thoughts!