The first rule of Fight Club is: You do not talk about Fight Club. The second rule of Fight Club is: You do not talk about Fight Club.
I guess the same could be said about refactoring. That would first requires to define what I mean by refactoring in the context of this post:
Refactoring is any action on the codebase that improves quality.
Which in turn requires to define what is quality. Everyone I’ve talked with agrees on this: it’s quite hard to do. Let’s settle for now for the following tentative explanation:
Quality is a feature of the codebase (including and not limited to architecture, design, etc.) which the lack of stalls further meaningful changes in the codebase. At the limits:
- 100% quality means changing the codebase to develop a new feature would require the smallest possible time;
- 0% quality means the time to do it would be infinite.
Given this definition, refactoring includes:
- Improving the design of classes
- Adding unit tests
- Removing useless code
- Following accepted good practices
- Anything related to improve readability
- etc.
Now back to the subject of this post. Should we ask the customer/manager if a refactoring is necessary? Should we put a refactoring sprint in the backlog? I’ve witnessed first hand many cases where it was asked. As expected, in nearly all cases, the decision was not to perform the refactoring. Taking ages to implement some feature? No design change. Not enough test harness? No tests added. Why? Because the customer/manager has no clue what refactoring and quality means.
Let’s use a simple analogy: when I take my car to the mechanic, do I get to choose whether he’ll check if the repairs have been correctly executed? Not at all. Checks are part of the overall package I get when I choose a professional mechanic. If choice was made possible, some people who probably opt not to do the checks - to pay less. So far, so good. But then if trouble happened, and probability is in favor of that, the mechanic would be in deep trouble. Because he’s the professional and didn’t do his job well.
Developers would also get into trouble if they delivered applications with no tests or with a messy codebase; not their customer nor their manager - especially not their managing (depending on their kind of manager if you catch my drift). So I wonder why developers have to let people that don’t know about code taking such important decisions.
As a professional developer, you and no one else are responsible for the quality of the application you deliver. Your name is in the source code and the commit history, not your manager’s. Stop searching for excuses not to refactor: don’t ask, do it. Refactoring is part of the software development package, period.