Therapeutic Refactoring

At a conference I attended a few years ago, Martin Fowler used the term "Therapeutic Refactoring" in response to a question. His explanation and a follow-on conversation convinced me that I had experienced the phenomenon that he was describing.[1]

Refactoring — improving the internal structure of code while keeping its behavior intact — is a key practice to which all self-respecting software teams give at least an honest try. "Refactoring" as a term has become so ubiquitous that it has leaped from software engineering into other disciplines: such as online publishing, hardware and biology.

By definition, refactoring has zero direct business value — the behavior of the code remains unchanged after the refactoring as no features are added, removed or modified. Of course, refactoring, if done in a regularly disciplined manner, provides significant indirect business value. I liken refactoring to the HR department of a company: the "People-People". This department by itself doesn't make any profit at all; but try disbanding this group in a healthy, profitable company and see how long the company survives.

Perhaps because of its nature as a source of indirect business value, software teams often find it difficult to do regular refactoring. This leads to badly factored code, and a tendency to "sell" refactoring directly to the business stakeholders as a valuable commodity. This approach inevitably fails — as the business is unwilling to spend money on code "that should have been written correctly in the first place". Ron Jeffries has written an absorbing article on the futility of this approach: Refactoring - not on the backlog.

Ron Jeffries' suggestion is to do refactoring as part of a feature story. My colleague, Emma Ritcey, shared with me her experiences of adopting this approach on a problematic Angular codebase she inherited. This is wonderful when it’s practiced; except that it can be hard to get started if you haven't done it before. And you don't learn it by aimlessly and lonesomely hacking through the thicket of "weeds, brush and undergrowth" in your code. So how do you get started?

This is where adopting refactoring as a communal therapy can be useful.

The team can have a soul-baring confession among themselves, admitting that their daily frustrations with the code won't subside until they themselves spend some time cleaning things up. The team can schedule a combined activity — replete with pizza and drinks, if needed — and enjoy team bonding while sanitizing their code.

Therapeutic refactoring has beneficial effects not only on the code but on coders, too. This benefit, in my experience, is just as rewarding as that of the resultant clean code.

Footnotes

[1] My friend Vishal Bardoloi reminded me of Katrina Owen's talk titled "Therapeutic Refactoring". She uses the term to define a related but different phenomenon. Perhaps we in the software in industry have much use for therapy, both individually and collectively! I am happy for a broad definition that encompasses multiple approaches to refactoring.