When to Refactor?

It depends on who you ask.

Ask a product or business person and the answer will be never. There is always a new feature to build, an existing feature to improve or an important bug to fix.

An engineer will hesitate to answer. Because there is always a new feature to build, an existing feature to improve or an important bug to fix. Refactoring takes time away from building new things. And the user’s needs are the highest priority.

Engineers recognise the importance of refactoring. It is an investment in the future; an opportunity to lay the foundation to make work easier by making code more understandable and reusable. It’s an opportunity to remove duplication and unused code. Every developer on your project will benefit: The current team, future joiners, and your future self. Refactoring should be part of our everyday work.

Yet, we spend more time talking about improving our code than we spend doing the work.

Why is that?

Work is like a hill. The need for refactoring often arises while working on a feature—refactoring is unplanned work. Stepping back and making changes that do not affect the functionality of an application slows down the delivery of planned work. The expectation is to ship fast. If I got a penny every time someone asks “When will it be ready?” As a result, software engineers avoid to take risks and make decisions and leave the call to someone more senior.

Chances are, the work you shelve now will have to be done at some point. Future refactoring will be more complex, with more use cases and edge cases to support. It will take more time and be more costly. When you discover the need for refactoring, there will be another piece of work you set out to do. And the cycle starts again.

Refactoring is like doing the dishes. Do them every night and you always have utensils you need available. Wait a week and you face a huge pile of dirty saucepans and plates exactly in the moment you want to cook because you are hungry.

The best time to refactor is now.