You know developers solve business problems with code. Taking this literally, you are so busy working on new features that you often find yourself taking implementation shortcuts. Under the pressure of the product team, you don’t have time to go back and clean it up.

You know, in the long run, this is not sustainable. Code shortcuts inevitably make product quality degrade. Still, while evident in hindsight, the idea is hard to sell to product folks.

So, what can you do about it? I found that opportunistic refactoring works great to balance product work with tech debt elimination.

I learned about the techniques and borrowed the term from the brilliant deck Workflows of refactoring by Martin Fowler. I noticed that I usually share this presentation early when I join a team.

The general idea is that you don’t separate product work and refactoring. Instead, you do refactorings in small steps as you work on the feature. Martin Fowler outlines three techniques. The context starts when you’re working on a feature:

Litter-pickup refactoring. When you come across an ugly piece of code or a suboptimal pattern, you clean it up. Sometimes, it’s referred to as the boy-scout rule: “Always leave the code better than you found it.”

Comprehension refactoring. Often, you must figure out what the current code is doing before working on the change. As you build a mental picture, spend some time moving that understanding back into the code. It will be easier to figure out next time for you or your colleagues.

Preparatory refactoring. As summarized by Kent Beck, “for each desired change, make the change easy (warning: this may be hard), then make the easy change.”

Does it work for your own code? It may sound like you do litter-pickup or comprehension refactoring for code written by others. I found that very often, I use these techniques for my own code, even for code that I wrote relatively recently — maybe, just as recently as a few weeks ago.

It may feel like refactoring slows down the progress. As someone who tried it once and then embraced it, I assert that the opposite is true. The benefits of constant refactorings are noticeable even in the short run. In the long run, their accumulated positive effect becomes even more prominent. Introducing a culture of small and constant changes makes engineers happier and reduces friction between product and engineering teams.

Things to read

• Workflows of refactoring by Martin Fowler
• An example of preparatory refactoring by Martin Fowler
• Refactoring – Not on the backlog! by Ron Jeffries