This post originated from an RSS feed registered with Agile Buzz by Laurent Bossavit. Original Post: The value of duplication Feed Title: Incipient(thoughts) Feed URL: http://bossavit.com/thoughts/index.rdf Feed Description: You're in a maze of twisty little decisions, all alike. You're in a maze of twisty little decisions, all different. Latest Agile Buzz Posts Latest Agile Buzz Posts by Laurent Bossavit Latest Posts From Incipient(thoughts)

If you manage developers, duplicated code might not look all that threatening to you. In fact, you may have sensible reasons to insist on duplication.

I can guess what you might be thinking, but trust me for a little while. Put yourself in that manager's shoes - you're a technically savvy person, or were at some prior point in your career. At any rate, you don't mind looking at code. You don't have the time to actually read any of it - you're way too busy managing.

Suppose you're looking at Bob's code which implements the logic for printing invoices. You've just been looking at Bill's code which implements the logic for printing quotes. Bill is an excellent programmer, and his quotes code looked flawless. You're happy to see that Bob's invoices code looks quite a bit like Bill's code. You make a mental note to give Bob a pat on the back soon.

Bob may or may not be as good a programmer as Bill, but it doesn't matter; he doesn't have to. The fact is, there is a right way to code the kind of reports that include quotes and invoices; or at least, Bill's way is one of the right ways. So why should Bob not copy and paste Bill's code, and tweak it to print the kind of report that's needed ? And if a further kind of report is needed, it's nice to know that whoever is assigned the task of coding it will just have to copy and paste Bill's (or Bob's) code.

Well, you must be on tenterhooks by now. Am I turning apostate from the noble principles of DRY, the Simplicity Rules, and merciless refactoring ? No, I don't think duplication is good, and I don't think it is in software managers' best interests to reward duplication. But I find myself looking at the issue from the other side.

DRY is a strategy. We invest time in refactoring duplication out of the code. That time investment is repaid later. There are fewer places to look for bugs. There are fewer places to apply bug fixes to. There are fewer places to modify when the requirements change. Those are all upsides of merciless refactoring; but all strategies have a downside - or at least the potential for one.

The potential downside of well-factored code is that no two places look the same. It's harder to find formal, superficial regularities that tell you "yes, this is nice code" or "no, this doesn't look right". This ups the ante for someone who would review the code without being intimately familiar with it. Well-factored code is going to be harder to "manage" in this sense than repetitive code.

The good news for the manager is that code which results from factoring out duplication tends to be reusable code. Instead of having Bob code like Bill, you can look forward to having Bob use Bill's components. That's a win too !