Overcoming the Fear of Refactoring
One of the key attributes we look for when hiring is a passion for continuous improvement. Refactoring is an important part of continuous improvement. It’s an essential practice in order to reduce technical debt, but is harmful if overdone. Knowing when and where to refactor is also a difficult balance to get right, especially when faced with a growing backlog and growing technical debt. You don’t want people to bury their heads in the sand to avoid this decision, so it’s essential to keep the passion for and practice of refactoring alive.
This article shares what we’ve been doing recently to keep the refactoring flame burning bright, from improving our induction, through to applying the learning to production code.
Our context
We have several feature teams that share a very large codebase. We have a few refactoring evangelists/veterans among several dozen developers. Some of our developers are very experienced, while others are graduates. Our codebase covers a spectrum of classic ASP with inline SQL, to ASP.Net MVC 5. Pockets of technical debt exist throughout.
Our approach - walking the talk
You can talk about refactoring, you can read about refactoring, and you can write about refactoring. But all of this is moot unless you actually bite the bullet and do it. Refactor some code, particularly some spaghetti code. Like forming any habit, it’s important to take action and get started, and then just keep on doing it. It also helps to do this with others, to keep you accountable and to help guide and encourage you when the going gets tough.
Coding katas are a great way of doing this. They allow a group to practice and learn in a safe environment, before returning to the coalface to apply their new or improved skills to production code. We’ve recently improved our induction process to include the Gilded Rose Kata, to give our new starters a common starting point for refactoring, test-driven development and working with legacy code.
To help upskill our existing developers, across all teams, we also recently took a developer from each feature team and ran a much trickier refactoring kata with them, using the Trivia codebase. This kata is no walk in the park; it required more than a day’s preparation by our leader (including attempting it in more than one language) and we then spent a day on it ourselves. Making this a cross-team event has several benefits:
It encourages cross-pollination of knowledge and technique between the teams.
It gives the teams some consistency and common language in their approach to refactoring.
It provides each team with a local evangelist to encourage more, better refactoring.
Spreading the word
Running a kata is no good if the new skills aren’t applied to real code. There’s also little benefit if the skills aren’t transferred to other team members. Therefore, our follow up to the kata is for each participant to work with their feature team to identify some really ugly production code to refactor. We then run a session with their team, focused on refactoring that piece of production code, and committing the improvements at the end of the session.
Refactor, rinse, repeat and refactor some more
None of the above can be just one-off activities. Our culture of continuous improvement means that we evaluate how these activities went, tweak them, and then run them again. Technical debt and the need for refactoring will always be with us, but hopefully we are getting better at balancing them. You can therefore expect another blog post on this subject in the future.
