Tech debt - When should developers refactor?

As software developers, our main goal is to write code that solves problems. In that essence, software developers are problem solvers who can remember syntax. But solving one problem often creates five new ones, and if these new problems aren't addressed, they can become what we call tech debt. What is tech debt Tech debt is a term for the extra work that a developer needs to complete in order to start building on top of already functional code. A simple example of this could be a React component that is too big and does too many things at once. So when a new developer needs to build something in this component, they must spend time understanding the long component, possibly split it up themselves, and may be obstructed from introducing new logic because the existing logic is not easy to build on top of. How to "pay back" tech debt Tech debt is usually fixed by paying it back with your time—by refactoring something you've already built. Just like with real debt, tech debt can start with a developer wanting to save a few hours on a project. Over time, the "debt" accumulates and gets bigger. A tech debt that started with a developer saving five hours can turn into a developer spending a week refactoring their initial solution. On the other hand, a developer can spend too much time refactoring—to the point where they spend 80% of their time ensuring that the features they ship are written with perfect code, also called clean code. To manage this well, I follow a few simple rules: Follow the DRY and 1, 2, 3 principles The DRY (Don't Repeat Yourself) principle states that you should not write the same code twice. Instead, you should create an abstraction that can be reused. The 1, 2, 3 principle goes hand in hand with DRY: the first time you write some code, you just write it. The second time, you cringe about having to repeat yourself. The third time, you start refactoring. In this context, refactoring usually means creating some sort of abstraction for your code that is reusable. When adding new features When adding a new feature—especially into code written by someone else—a great place to start can be refactoring some of it. By doing this, you kill two birds with one stone: you clean the code and gain a deeper understanding of how it works. When fixing bugs Bugs often hide within complex logic. By refactoring, these bugs tend to reveal themselves and become easier to fix. When you're code reviewing If you work at a company where code reviewing is part of the development flow, reviews are the perfect time for reviewers to point out parts of the code that need refactoring. Make it work, make it right, and make it fast This final principle is helpful when building new features. First, make it work—ensure the functionality the end user needs is there. Then, make it right—write clean and reusable code. Finally, make it fast—optimize performance if needed, such as speeding up slow query times. Conclusion I hope this guide was helpful in highlighting key situations and principles. Consider commenting on what other principles or rules you follow when refactoring code.

Apr 29, 2025 - 20:23

Tech debt - When should developers refactor?

As software developers, our main goal is to write code that solves problems. In that essence, software developers are problem solvers who can remember syntax. But solving one problem often creates five new ones, and if these new problems aren't addressed, they can become what we call tech debt.

What is tech debt

Tech debt is a term for the extra work that a developer needs to complete in order to start building on top of already functional code. A simple example of this could be a React component that is too big and does too many things at once. So when a new developer needs to build something in this component, they must spend time understanding the long component, possibly split it up themselves, and may be obstructed from introducing new logic because the existing logic is not easy to build on top of.

How to "pay back" tech debt

Tech debt is usually fixed by paying it back with your time—by refactoring something you've already built. Just like with real debt, tech debt can start with a developer wanting to save a few hours on a project. Over time, the "debt" accumulates and gets bigger. A tech debt that started with a developer saving five hours can turn into a developer spending a week refactoring their initial solution.

On the other hand, a developer can spend too much time refactoring—to the point where they spend 80% of their time ensuring that the features they ship are written with perfect code, also called clean code.

To manage this well, I follow a few simple rules:

Follow the DRY and 1, 2, 3 principles

The DRY (Don't Repeat Yourself) principle states that you should not write the same code twice. Instead, you should create an abstraction that can be reused. The 1, 2, 3 principle goes hand in hand with DRY: the first time you write some code, you just write it. The second time, you cringe about having to repeat yourself. The third time, you start refactoring. In this context, refactoring usually means creating some sort of abstraction for your code that is reusable.

When adding new features

When adding a new feature—especially into code written by someone else—a great place to start can be refactoring some of it. By doing this, you kill two birds with one stone: you clean the code and gain a deeper understanding of how it works.

When fixing bugs

Bugs often hide within complex logic. By refactoring, these bugs tend to reveal themselves and become easier to fix.

When you're code reviewing

If you work at a company where code reviewing is part of the development flow, reviews are the perfect time for reviewers to point out parts of the code that need refactoring.

Make it work, make it right, and make it fast

This final principle is helpful when building new features. First, make it work—ensure the functionality the end user needs is there. Then, make it right—write clean and reusable code. Finally, make it fast—optimize performance if needed, such as speeding up slow query times.

Conclusion

I hope this guide was helpful in highlighting key situations and principles. Consider commenting on what other principles or rules you follow when refactoring code.