Published April 12, 2017 · 4 min read

Duplicate code isn’t something we usually want in our code for various reasons. The most obvious one is maintenance. When you change a piece of logic, you have to find every place where it appears and update them all. A deeper reason lies in the proper use of design principles, such as Don’t Repeat Yourself (DRY). Although it’s hard to argue against these ideas, I still believe duplicate code can sometimes be acceptable. Sometimes it's even helpful.

Over the years, I have learned that a little duplication can make your code more readable and understandable. While DRY teaches us to avoid repetition, our real goal isn’t to follow the rule itself. The real goal is maintainability and clarity. DRY is a tool, not a religion.

Code duplication is not that bad

Readability Often Matters More

If duplication improves readability, it might actually serve that goal better. One of the clearest examples is setup code in testing. You could technically extract helper functions, but doing so can make tests harder to read because the reader has to jump between files or methods to understand what data is being created. Sometimes, keeping that code inline makes it easier to see what is happening.

For example:

@Test
public void calculate(){
  Dog dog = new Dog();
  dog.setName("karabas");
  dog.setAge(3);
  Human human = new Human();
  human.setAge(41);
  human.setDog(dog);
  ...
}

@Test
public void calculateWithSmallerGap(){
  Dog dog = new Dog();
  dog.setName("karabas");
  dog.setAge(3);
  Human human = new Human();
  human.setAge(7);
  human.setDog(dog);
  ...
}

Here, I can clearly see two pieces of duplicated logic — one for creating a Dog and another for creating a Human. I could extract helper functions, but the tests would become less direct. This duplication makes the code easier to follow, so I prefer to keep it that way for a while.

Premature Abstraction Can Be Worse

Removing duplicate code too early is a form of premature optimization. Refactoring for the sake of cleanliness alone can make things worse or lead to unnecessary abstraction. It’s wiser to focus on keeping the code clean and well-tested. When the right time comes, duplication reveals its own refactoring opportunities naturally.

Here’s another example that illustrates this process:

function calculateSimpleSalary(base, bonus, isOverAchieving){
  let total = base + bonus;
  if(isOverAchieving){
     total += (base \* OVER\_ACHIEVING\_PERCENT) / 100;
  }
  return total;
}

function calculateOvertimeSalary(base, bonus, overtime, isOverAchieving){
  let total = base + bonus + overtime;
  if(isOverAchieving){
     total += (bonus \* OVER\_ACHIEVING\_PERCENT) / 100;
  }
  if(isOverAchieving){
     total += (overtime \* OVER\_ACHIEVING\_PERCENT) / 100;
  }
  return total;
}

At first glance, these two functions share obvious similarities. You could create a helper for overachieving salary or reuse logic between them, but at this stage, it might be too soon. The codebase is still young. The duplication is tolerable because it’s easy to understand and test. As the system grows, patterns will emerge, and refactoring will become obvious.

Later, when we add more related logic, the right moment arrives:

function calculateAfterTax(salary, isBonus){
  let tax = isBonus ? (salary \* TAX\_ON\_BONUS) / 100 :  (salary \* TAX\_ON\_BASE) / 100;
  return salary - tax;
}

function calculateAfterTaxSalary(person){
  let totalSalary = calculateAfterTax(base, false) + calculateBonusAfterTax(bonus, isOverAchieving);
  if(person.hasOvertime()){
     totalSalary += calculateBonusAfterTax(person.overtime, person.isOverAchieving);
  }
  return totalSalary;
}

function calculateBonusAfterTax(bonus, isOverAchieving){
  let totalAfterTax = calculateTax(bonus, true);
  if(isOverAchieving){
    totalAfterTax += calculateTax(bonus \* OVER\_ACHIEVING\_PERCENT / 100, true);
  }
  return totalAfterTax;
}

At this point, refactoring makes sense. The duplicated patterns are now stable, and abstraction brings real value.

Let the Code Mature

Duplicate code is not inherently bad. It becomes a problem only when it grows uncontrolled or starts causing inconsistency. In the early stages of development, clarity and stability are more important than elegance.

Principles like DRY, SOLID, and KISS are meant to guide thinking, not limit it. Let your codebase evolve naturally. When duplication starts to feel heavy, that’s when it’s time to refactor, not before.

In conclusion, we can live with duplicate code for a while. Sometimes even longer. While duplication goes against established design principles, those principles are only means to an end. The real goal is to write code that is understandable, maintainable, and easy to change.

Let the code mature. Refactor when the repetition starts to hurt, not when it merely exists.