Refactoring - When?

Always?

And the simple answer to when refactoring is a good idea: always. You should never stop refactoring.

Software creation has only one constant, and that constant is change. When you write a piece of code, you don’t ask yourself whether the requirements for that part will change. They will, sooner or later, and it’s only a question of when. Be ready for it. You should always refactor at least a small part of what’s around your ‘current’ code.

The best solution to how we can keep the refactoring going is to make everybody (including product owners and project managers) aware of its significance. They need to know it’s indispensable, and not merely a consequence of poorly written code. The need for refactoring is one of the perennial features of software development.

With everybody on board, your team should be able to make it a part of your standard sprint plan. How much of the sprint should be spent on refactoring? That’s a very case-specific question. Spending an entire sprint on rewriting code feels wrong, but you need to designate some of your time to it. Getting the balance right - between giving refactoring its due and knowing where to stop - is one of the virtues to be found in great senior developers and tech leaders.

Never.

There are a few cases in which you should most likely never refactor. However, due to the fact that a lot of developers are passionate about their work and want to do it in the best way they can, they will often suggest refactoring out of sheer love for clean code. That’s admirable, but it’s not always the best strategy for business. Therefore it’s the responsibility of the business owners/managers to recognize those cases in which we shouldn’t refactor.

Your nevers:

• You should never refactor just after your team has taken over a project from another team. Developers will always complain that the codebase is ugly and requires fixes, but it’s actually more important to familiarise yourself with it before you start rewriting parts of it. Many programmers think that just because they don’t understand the code, it’s ugly - and that’s not true. When starting the project, your first weeks should be focused on delivering tickets or doing bugfixes if it’s required. This is the best way to get to know the codebase and make conscious decisions about what needs refactoring
• You should never do a sizable refactoring in one huge chunk that blocks the rest of the development - more on that in our ‘refactoring - how?’ post
• You should never rewrite from scratch - it’s the worse option in 99% percent of cases. Most of the time, development teams and leaders push for complete rewrite because the current codebase is ugly, has a lot of bugs, and is poorly designed. Sadly, in this scenario it’s probably also very large and features remain undocumented. Would you start a new project without defining its scope first?

TL;DR

To wrap this small series up:

• always refactor,
• plan it with your team, make it a process,
• make sure you know all the right reasons,
• and the rest of your team knows them too,
• balance your current features and refactorings - if you don’t know how, 80% features - 20% refs will get you going.

Happy refactoring!

Now that you know when to do refactoring, find out more about the why and how. Enjoy!