So then, it's pretty easy: just don't duplicate the code, right? It's basically as easy as saying don't eat bad food. Some people have the discipline to stick to healthy nutrients to an extent to which they find junk food disgusting, but the rest of use enjoy a juicy burger once in a while.
Image by Sam ULAs noted by Dave Thomas, one of the two authors of The Pragmatic Programmer:
If you have more than one way to express the same thing, at some point the two or three different representations will most likely fall out of step with each other.To keep these representations up to date and therefore synchronized with each other, you'll find yourself stuck in the wasteful process of changing them in parallel, which I call the maintenance nightmare. And the nightmare reaches its climax when contradiction makes its way in.
The duplication plague extends beyond code. It reaches areas such as requirements or specifications as well.
It happened to me a couple of times to be directed to obsolete documents, when I started in a new team. These documents usually become obsolete because a colleague sends an email with a few notes, which become new requests upon subsequent replies.
Later on, someone else puts together a Word document that summarizes what has been discussed, which will probably get to be obsolete in a couple of weeks.
A solution that I found working was to establish a procedure of maintaining specifications and, more importantly, to stick to it. This may sound overblown, but it doesn't need to be: a simple guidance, presented as text is usually enough and also newcomers will benefit from it.
When a new email comes in with notes on how a process or a feature must be changed, make sure to update the single location where it was described so far and point everyone to it. Referencing that location in future discussions will habituate your co-workers into using the procedure you established together, eliminating the confusion induced by obsolete docs.