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?

  • 3
    Look at your devs. The more bitter they are, and the more they laugh at you over time lines that were practical last year, the more work needs to be done on making the code base developer friendly.
    – Kain0_0
    Feb 4 at 22:32
  • 6
    Canonical answer: osnews.com/story/19266/wtfsm
    – Doc Brown
    Feb 4 at 22:36
  • The problem comes when the dev team is comprised of amateurs. The WTF/minute is non-existent.
    – Laiv
    Feb 5 at 8:19

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.