Refactoring offers a massive opportunity to increase your deployment frequency. Done consistently, incremental and well-tested refactorings will become a major component of your release culture.
As an engineering leader, you need to understand five things about refactoring:
- Refactoring is a daily job. Refactoring is not a periodic exercise intended to last weeks or months. When your engineers ask for long periods to refactor, interpret their request as a sign that they don’t have either the skill or a plan to actually perform the refactoring. You can address this problem by asking your engineer to decompose the refactoring into smaller batches. If they cannot successfully decompose the refactoring, there is zero chance of that refactoring going well.
- You will not get permission from the business to refactor code. Refactoring sounds like rework and it’s unpalatable, even to engineering-oriented business leaders. But refactoring is part of your job, like weeding is part of a gardener’s job.
- Successful refactoring requires a specific purpose. Why are you refactoring this code? To add new functionality? To improve testability? To improve readability? When your engineers talk about refactoring, push them to explain the customer value and the impact on your team’s ability to deploy frequently.
- When you review a PR with a patchwork fix, directly ask the engineer to refactor the code instead. Give your engineers permission to refactor, but timebox it appropriately. Without a timebox, your engineer may interpret this as permission to spend a week or more performing a small and low value refactor.
- Celebrate when engineers refactor code. Remember that culture is what you celebrate and tolerate.
Leave code better than you found it. Refactor and refactor often.
