When is it OK to Copy Code?

You may have heard the software development principle ‘don’t repeat yourself’, or DRY. I stick to it was well as I can, but I have been trying to think of a list of exceptions. When is repeating yourself ok?

And by ok, I still don’t mean good, but at least less bad.

Logic vs Structure

Structure, the boiler plate stuff that allows you to implement logic, is a less important place to avoid duplication than in the logic itself. It should still be avoided, but it’s not as egregious a foul. When I talk about structure I typically mean things like getters and setters, set up for making SOAP calls, and generated code. Like structure, there are different types of logic. Of these, business logic is the one in which duplication should be most strongly avoided. This is often a difficult problem, since the same logic is often required in both clients and servers, in different libraries, and even in different languages. But business logic often changes frequently, and that makes reducing duplication a worthwhile effort.

Production vs Other

I hold production code to the highest standard. This is the code that gets used by customers on an ongoing basis, where quality is most important. Other types of code such as utilities, data conversion code, and tests are less important. Yes, even though tests are often delivered with an application, their use only applies to development of new features and not regular use, so it is often not worthwhile to spend large amounts of time reducing duplication there. Focus on reducing duplication in production code and generating more test coverage, rather than improving the quality of test code.

Exceptions

You can’t always avoid duplication even in the above situations. One example of this is when you do not have the ability to modify source code and in order to extends its capabilities you first have to copy it. Or some existing code is part of a production system that cannot be modified until a replacement system has proven its value. But these are rarities, and should be approached on a case-by-case basis.

Thanks to my brother Angus for his input on this article.

Leave a Reply

Your email address will not be published. Required fields are marked *