What Happens When We Misuse Refactoring in Conversation?

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.

I’m thankful one of the giant robots at Thoughtbot wrote this so I don’t have to.

After a while, long periods of work with no result creates distrust.

Results build trust! Results come in the form of desirable change or desirable predictability. Refactoring is focused on not introducing change, so it must be focused on retaining predictability.

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.

Say what you mean and mean what you say.

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.

Amen.