In a 2017 post German Velasco wrote about how to think and do refactoring right. This is a follow-up post about what goes wrong when we misuse refactoring and (in German’s words) “rob ourselves of the power to communicate an important concept”.
Done well, refactoring is a low-risk investment in future productivity, by reorganising code without changing its behaviour. Often however, our conversations position work that doesn’t meet this description - and needs more scrutiny - as refactoring. Let’s look at what goes wrong when this happens.
As an aid to conversation, let’s start with some examples of misuse (based on real team conversations):
- “refactor” a mobile app component so that it handles disabled device location (this was not refactoring, it was a bug fix)
- “refactor” to v2 of a third party web API (supporting v2 would require lots of change)
- “refactor” for performance (we want a significant improvement - or why bother - meaning that the code behaves differently)
- “refactor” from synchronous to asynchronous communication (the users would get the same end result, but the code and their experience would be very different)
All of these conversations described important work that I don’t mean to discourage. Still, none of them was really about refactoring. This use of the word “refactoring” seems to signal that the speaker is thinking technically, but not about what refactoring really implies.
Misusing “refactoring” sabotages important conversations
Refactoring is a technical word typically describing a series of quick, well-understood, easily reverted changes that a single developer (or pair) makes. German’s post describes this really well.
Misusing refactoring to describe work that doesn’t fit that description avoids important conversations about:
- Prioritisation: the product will change, but there’s no conversation about whether the product needs the change, or why now. Higher priority work slows down or even becomes blocked.
- Scope: the change is not well understood, but “refactoring” implies that there is no change worth discussing. We’re not defining success, more and more cases feel like they need to be addressed immediately, and the work never ends.
- Collaboration: without conversation about the necessary skills and context (or who would help), we produce bad (or scrapped) code.
- Capacity: refactoring implies that this is a small piece of work, but since we’re not really refactoring we could be taking on a large task that the team cannot accomodate.
Successive failures lead the team to avoid (real) refactoring
After a while, long periods of work with no result creates distrust. People learn to stop listening (or become hostile) when “refactoring” comes up. That increases the chance of failure even further, because real refactoring is a powerful tool, and teams lose out when they dismiss it.
Restoring faith in real refactoring
Ideally we would be successful at both refactoring and other kinds of change. Below are two ideas that can help.
Find more specific words for non-refactoring work
Remembering that the examples above are not refactoring but are still important work, here is some improved wording for a better conversation:
- fix the bug where my component doesn’t handle disabled device location
- migrate to v2 of the third party API because v1 is being deprecated by its authors
- improve order read performance by 30%
- change to asynchronous communication to handle cases where the client and the server get disconnected
You may notice that there is more detail in the reworded examples. That’s intentional. When we stop using “refactoring” with an audience who don’t understand the word, we’re more likely to get into helpful specifics. A listener is more likely to ask: “why do I need this change and not something else?”, or “what does success look like?” when meaning is not hidden.
Learn more about refactoring
If we understand refactoring correctly, we’re not going to misuse it in conversation, and we stand more chance of success when we do need to refactor. Experience has taught me that refactoring without proper understanding is very likely to fail. For this I’ll point you for a third time to German’s blog post; for further reading it’s worth going into the books he cites.
Conclusion
We need to be careful not to claim that we’re refactoring when we’re really making bug fixes, adding new features, or otherwise changing the code’s behaviour and our product’s user experience. Disguising that work as refactoring sabotages important conversations and creates suspicion about the concept. We can fix this by getting more specific in our language and by learning more about what refactoring really is.
