As programmers, we have long learned that Duplication is the Ultimate Sin of programming. Even considering to duplicate something is almost unthinkable.
But removing duplication introduces dependencies. If you and I use the reuse the same piece of code instead of duplicating it, changes I make may affect you. This effect can anything from beneficial (I fixed a bug you also needed fixing) to benign (I added a new feature that you’re not using) to detrimental (I want it to work in a way that’s no good for you).
When we have dependencies, we have to think: “Perhaps I shouldn’t add that feature – what if breaks something for someone else?” “Damn the torpedoes, I’m hacking it in!” or “Perhaps I’ll just make a fork for my changes and we’ll merge later”.
Sometimes benign, sometimes harmfull.
I recently discussed with a friend the case of being innovative in the face of legacy code. Remember: Legacy code is code that you don’t want to touch, because it’s dangerous to change and it gives value to the business now.
We want to gradually build a new platform. So it seems like we have two choices: We could make the new code call functionality on the old platform (ick! because, you know, “stop digging“) or we could build a new service and change the old system to use it (OMG! because, you know, “dangerous to change”).
If we allow the new system to duplicate as much functionality as needed from the old system, this false dicotomy goes away.
Duplication isn’t a cardinal sin. It’s a negative property, but in many cases, it could be your best option.
| Reference: | Are you getting worked up over code duplication? from our NCG partner Johannes Brodwall at the Thinking Inside a Bigger Box blog. |
