Allow yourself to duplicate code


Imagine you are writing a function that returns an object:

func do() {
  return {a: 1, b: 2, c: 3}

However, you noticed that there are three other similar functions across different packages that perform almost the same thing:

// package-a
func do() {
  return {a: 1}

// package-b
func do() {
  return {a: 1, b: 2}

// package-c
func do() {
  return {a: 1, b: 2, c: 3, d: 4}

As a responsible developer, you feel the urge to extract the common pieces, allowing all existing functions as well as your new function to reference that common piece.

After all, duplicating code is a practice that should be avoided whenever possible.

Why we avoid duplicating code

The Don’t Repeat Yourself (DRY) principle is a fundamental concept in reducing code duplication and information repetition. While there are technical reasons for practising DRY, there may also be psychological and social reasons to do so.

Here’s my take.

During college, undergraduates often focus solely on getting a system or program to work, without much concern for code structure and modularity.

However, upon entering the workplace, there is a shift towards advocating for better code structure and hygiene, including reducing code duplication through the DRY principle. Practising DRY may be seen as a sign of technical competency. If seasoned developers are still duplicating code, they may be perceived as no better than fresh software engineering talents who have just joined the workforce.

This subconscious desire to appear technically competent to our peers could be a subconscious, yet major force driving us to apply the DRY principle.

“Allow yourself” to duplicate code

The title of this post starts with “Allow yourself”. If the reason for avoiding code duplication is psychological or social, it’s not something that can be reasoned with rationally. Instead, it’s an ingrained thought process that each developer must question.

Duplicating code might seem like something a rookie would do, but sometimes it is also the right thing to do. Consider the following technical benefits of duplicating code:

Besides the DRY principle, there are other principles that suggest interesting alternatives, including WET (Write Every Time) and DAMP (Don’t Abstract Methods Prematurely), although they may not receive as much spotlight as the DRY principle.