This short series of blogposts answers the "why", "how", and "when" of code refactoring.
If you are...
...then this blog post was made just for you!
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.
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.
To wrap this small series up: