I'm working my way through Refactoring: Improving the Design of Existing Code by Martin Fowler and I came across the following passage (2nd ed, p. 55, emphasis mine):
To a manager who is genuinely savvy about technology ... refactoring isn't hard to justify. Such managers should be encouraging refactoring on a regular basis and be looking for signs that indicate a team isn't doing enough.
As a team lead or member, how can I determine that my team isn't doing enough refactoring?
This is a great question. First of all, developers who are refactoring talk about refactoring. They mention the need for it when you ask for estimates. They mention they did it when they give status updates. They ask for help from other developers to do it.
If you're a coder, you can look in the code for the smells that are mentioned in that book, especially in reviews of new code. When programmers don't refactor enough, their pull requests will sometimes contain bizarre workarounds to avoid a refactor. In severe cases, authors will complain when asked to do refactors in pull requests.
Other signs that refactoring isn't happening often enough take a while to build up. One of these is that estimates blow way up. Your developers will think something will take a day and it takes two weeks. The bugs will be more difficult to keep on top of. Those things can happen for other reasons, but lack of refactoring makes it worse.
As a manager, you shouldn't really worry about specific practices your developers use. Instead, you should monitor how healthy the whole project is in terms of adding new features. As not doing refactoring, and dozens of other stuffs, often leads to bad estimates, buggy code, and long cycle times.
And those are things you should track. Ideally, your engineers should give you somewhat reliable estimates for small tasks. There should be zero bugs that result in bad things in production. And development cycle time should be low and stable. So you start measuring those, visualize them for all the stakeholders to see, make it clear to your engineers that you are willing to invest time and money into keeping those metrics in the green, and open a conversation with them if those metrics get red.
