Where i work, people (consultants) feel pressed to release features as fast as possible. So instead of spending too much time on thinking about how to do things the right way or because they don't want to break anything, code gets copied from different modules and modified.

It's not easy to prevent this, since the code base is open to the whole company. Lots of people work on this.

Now that the mess is there already, what is the best way to remove those redundancies without breaking too much?

  • 3
    The most annoying thing is when code gets copy/pasted from some site and then even the comments don't get deleted. So you can find: "//Thanks for that Carlo"... And when you point it to them they just laugh and say:"Leave it! ))". That's not professional and sad!!!
    – CoffeeCode
    Feb 2, 2011 at 9:51
  • 3
    its not only consultants
    – AndersK
    Feb 2, 2011 at 11:44

10 Answers 10


One part of the answer is Refactoring.

First, start writing unit tests to ensure that you don't accidentally break anything with your changes. Then start improving the design, removing duplications etc. in small steps, running your unit tests after each step, fixing any problems if any of the tests fail, or reverting immediately if you run into a bigger problem than you can solve easily.

The other part is education.

People must be taught not to leave bad code behind. This is certainly a long term battle, as habits and thought processes are hard (sometimes even impossible) to change. However, without it, you will just continue to get an endless supply of bad code screaming to be refactored.

You may choose to do group code reviews to open discussion about good and bad coding habits, and spread the merits of the former. It is not enough to say "you must (not) write code like this", you need to convince people with logic and hard facts. Like "if you have this piece of method duplicated over the codebase n times, what do you think the chances are that if a bug is found in that method, it will be fixed in each copy of the method code?"

Your company may also need to revise the incentives and acceptance criteria for the consultants - if they can get away with writing sloppy code, they will surely keep choosing the easier path. If the company keeps valuing "fast delivery" over long term maintainability, nothing will change :-( So you may need to discuss this with management as well. One way to make them understand is this: refactoring means keeping the code clean, easy to understand and maintain. Omitting refactoring is like amassing debt on your credit card. You can get away with it for a while, but if you are not actively managing your buying habits and debts, it will inevitably crumble on your shoulders one day. In the life of a software project, bankruptcy is when the project becomes unmaintainable: it becomes easier to rewrite it from scratch than to add a new feature to the existing codebase. Or users get so fed up with the inferior level of support and features that they simply switch to the competition.

  • 4
    "First, start writing unit tests to ensure that you don't accidentally break anything with your changes." Woah, pump the brakes there. I really dislike how everyone on the SE sites throw this line in their answer so nonchalantly. This is extremely hard to figure out and is not so casual as 99% of the users who suggest it make it out to be.
    – Sergio
    Feb 2, 2011 at 13:54
  • @Sergio Tapia - true, but you can't refactor without it. Welcome to reality, circa 2011. Feb 2, 2011 at 14:09
  • 1
    @Sergio, if you mean that unit testing legacy code is hard, I couldn't agree more. I am happy to extend the quoted sentence as "First, you should start the arduous and stressful task of writing unit tests ..." :-) However, if you mean that since unit testing is hard, one should try to get by without it, I strongly disagree (based on practical experience, not theory). There is no royal road to maintaining legacy code. Feb 2, 2011 at 14:20

As part of education like @Peter said, you can introduce a copy & paste detector like PMD and use it as part of your build cycly to help enforce this part of your coding standards.

Make sure that your projects coding standard covers this pattern so that you have a baseline to start discussions from.

  • 1
    I like this, nice one!
    – ozz
    Feb 2, 2011 at 10:00
  • Is it possible to require adherence to a coding standard in a contractor's contract?
    – Armand
    Feb 2, 2011 at 10:38
  • 1
    @Alison You can require adherence to whatever you like, as long as you state up front you shouldn't have a problem. As a contractor I adhere to whatever development requiremnts the companies I work at have, one of them is being consistant with their coding standards. Reviewing of code before submitting to the trunk could also help solve this Feb 2, 2011 at 11:08
  • Thanks, after your post i also found clonedigger.sourceforge.net for Python/Java. Feb 2, 2011 at 11:09
  • @G3D makes sense; do you like having a coding standard to work to? My issue with code reviews as a form of acceptance is that as a contractor I would be worried that the code could be rejected for arbitrary reasons (e.g. politics, or changes in budget)
    – Armand
    Feb 2, 2011 at 11:19

people (consultants) feel pressed to release features as fast as possible

You don't have a technical problem, you have a social problem. Indeed, you have a management problem.

It's not easy to prevent this, since the code base is open to the whole company. Lots of people work on this.

The "code base is open to the whole company" is a non-issue. Doesn't matter.

What matters is that there's a management reward system in place for copy-and-paste. The root cause is that people are rewarded (i.e., paid or praised or promoted or extended) for copy-and-paste.

You cannot break this without fundamentally changing the culture from "pressed to release features as fast as possible" to "rewarded for making the appropriate, well-tested code-base changes."

You have to

  1. Start at the top, with the managers that reinforce the rewards. You have to expose the current practice and document the costs and risks. You have to propose an alternative that reduces costs and risks.

  2. You have to relentlessly document and expose cost and risk for the rest of your tenure at that organization. Relentless. Fact-based. Cost and Risk. Every week more cost and more risk from copy-and-paste.

  3. You'll have to help managers take credit the new approach which will make them look good and you will be ignored.

It's very important to reduce copy-and-paste. But it's hard to change an organization's culture. You have to provide a lot of facts and you have to make the case over and over again to manager's who don't agree with you.

  • 1
    +1 especially for "You'll have to help managers take credit the new approach which will make them look good and you will be ignored.". Better be prepared that all too often this is reality :-( Feb 2, 2011 at 14:32
  • @Péter Török: Too many people give up on this. They either don't collect the facts on problems caused by copy/paste or they don't keep making the case to management again and again.
    – S.Lott
    Feb 2, 2011 at 14:34
  • I know there is a deeper, non-technical problem here. But it's a problem noone who cares can fix anytime soon. It's like a bug in a third-party library you need to work around. Feb 2, 2011 at 15:12
  • @Lenny222: Your comment makes little sense. "it's a problem noone who cares can fix anytime soon" is clear form the question. What does this comment mean? What is missing from the answer? What more do you need?
    – S.Lott
    Feb 2, 2011 at 16:17
  • This will be a continuous education process.
    – JeffO
    Feb 2, 2011 at 17:04

I have a code base now that was starting to rot from that. I had over 10 static functions per module that were basically identical to the same static functions in other modules. Each one behaved just differently enough to warrant a new incarnation in the sake of doing things as quickly as possible.

Today, I had to add yet another feature and I just couldn't take it any more. I created a new library, combined the 100 + functions into 10 reentrant functions that slightly alter their behavior based on bit flags and then wrote a series of tests to make sure any changes to that library didn't break anything else.

Total time spent: 4 hours. I was ready to go on a 20 hour marathon if needed and was surprised at how quickly I brought a growing mess under control. As a bonus, it was easier to subsequently fix a bunch of header dependency issues. Additionally, since a lot of our proprietary stuff is now in static objects for linking, we can give our customers who get access to source code more than we did previously.

My advice: bite the bullet and re-factor that mess now before doing so really gets bad. It probably won't take as long as you think, but create a new branch for yourself just in case.

Additionally, you can still copy / paste to get features out the door while fixing the fundamental issue. When you're done, just rip out the pasted stuff and use the new library instead.

  • Curious, did you find any that were identical?
    – JeffO
    Feb 2, 2011 at 17:07
  • @Jeff - Yes, a few. But mostly the pattern showed that duplication was a result of someone wanting what (should be) library code to do something a little different.
    – user131
    Feb 3, 2011 at 7:53

I agree with the answers given so far. You should:

  • create unit tests
  • refactor
  • educate
  • put effort into coding standards and detect violations

But on the other hand you need to look at what causes people to copy paste and fix that.

  • people might not be able reuse code in a good way because it is coupled to much
  • people might not know that there is a library that they can use
  • The library code might not be generic enough and baking your own version is way easier than using an existing library
  • There might not be a good versioning (not source control) strategy and changing a generic library might just cause to many other applications to be tested also.

So I think to stop the copy/paste pattern you need to make reuse easier.

  • make libraries discoverable and well documented
  • make the libraries independent of everything
  • think of a good versioning strategy
  • ensure backwards compatibility
  • think about easy extensibility of the libraries

read Framework Design Guidelines

Hope this helps.


There is a strong "copy paste considered harmful" attitude. I think it's good, but goes a little bit too far. Copy paste as an exercise in discovering the similarities and differences between two methods or classes - as a step in the process of triangulation - I think is healthy. But stopping short of complete triangulation - of eliminating the duplication introduced by copy paste - is indeed harmful.

If you can find ways to use that more nuanced attitude, to tell developers not "that's bad!", but rather "that's incomplete, can you work with me to complete the refactoring?", then you may find yourself holding more constructive conversations.


I'm concerned with the same problem here, and my take on it is: Don't try to avoid it upfront, just refactor when it gets too bad.

The module I'm currently working on startet as a copy of another module, now I'm changing everything that needs to be different. Once this is done, and the new module is finished, I will compare it with the original module and find out which parts are more-or-less unchanged and should be moved to a library, abstract parent class etc.


Whoever is in charge is at fault. One person can't be expected to review every line of code, but they do set the standards and the timeframes.

Contractors (or anyone who is short-term on a project) can be put into the position where they are only compensated for making it work the first time. There is some incentive to get it done ASAP. The copied code may never need to be modified and if it is it won't be by them.

You could try and force them to fix it on their own time. Then they'll start doing it from the beginning, but then take an innordinant amout of time to get things done. I think AmmoQ has the right idea of refactoring things that are causing problems.

  • I agree. The thing is that project managers have no incentive to pay more for well-designed code. If i have to waste a week, they are not charged. Feb 2, 2011 at 15:11
  • @Lenny222 - what you can strive for is to pick your spots on a project to make the code better. The selling point for the PM won't happen until they come back (usually with tail between legs) and need what they feel will be a major change only to hear your response of 'no worries, we built that part to be more flexible'. They may learn eventually that there is a right way to do things and manage client's expectations. Everybody wants quality software, but few know what it really costs.
    – JeffO
    Feb 2, 2011 at 17:02

The only way to eliminate copy/paste code is (IMHO) code reviews, have a person (or preferably more) to check through the code and when they find code that seems to be from a copy/paste action let the programmer refactor.


As suggested this is mainly an problem in the organization. Try to start by educating people (don't forget the direct management layer above your position). It helps very much to start to get one or two people on your train and let the virus spread. When the majority thinks this is a good idea get it described and try to introduce reviews to guarantee it stays this way. This is a very slow and tedious process but it just can't change fast. At first it will cost extra time so it is important management knows and supports the long term goal.

@Anders K. Reviews are a good means to keep the practice in place. When forcing people to write code they don't believe in it creates a lot of friction. They will fall back in the old habbit as soon as the can. I firmly believe you should start with education to gain momentum.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.