Why Do Teams Discourage Refactoring?

I’m frustrated by my inability to convince members of my team to learn and practice refactoring. I’m frustrated by how often I see refactoring actively discouraged.

Martin Fowler defines a refactoring as a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior. Refactoring as an activity means to restructure software by applying a series of refactorings without changing its observable behavior. Notice that Fowler distinguishes between the activities of refactoring and restructuring: refactoring is a very specific technique to perform the more general activity of restructuring.

Michael Feathers defines legacy code as code without tests. If you work with such code you have to be very careful to avoid breaking working code whenever you change code. You might choose to adopt a rule of thumb like “whenever I make a change I will try to perturb the existing code as little as possible.” Anyone who has internalized this rule of thumb is going to be very wary of refactoring.

As developers we are constantly under pressure to deliver features. You may knowingly choose to take shortcuts while imagining some future where you can go back and instead do things right. You might choose to adopt a rule of thumb like “I know what I’m doing isn’t quite right but given a chance to go back I would know how to make things right.” Anyone who has internalized this rule of thumb is going to view refactoring as a sanction to unleash their pent up desire to go back and restructure code to make things right.

The combination of these two rules of thumb often produces a strange set of team behaviours. Developers are reluctant to refactor as they develop features. Instead they lobby their team for permission to explicitly refactor afterwards. By not refactoring at a smaller scale the team usually doesn’t have the experience nor the skills to perform refactoring as a sequence of small behavior-preserving changes. If those same developers are able to negotiate for explicit refactoring time, they often botch it up and now project leaders also become wary of refactoring.

It doesn’t have to be this way.

Leave a comment

Your comment