The development team gathers to find a solution to cut technical debt.
“We cannot finish this feature in time. We need to change too much code to do it”. Joe, the technical lead, was always direct and honest.
“What would help?” Bill, the manager, was not happy, but he trusts Joe. If he told him that’s a big problem, he’s certainly right.
“We need to refactor parts of the code”
“How long would that take?”
“I guess about two weeks.”
“Fine, let’s do it” Bill is still not happy, but what else can he do?
I’m sure you have seen this story happening again and again. Usually the team asks for a “refactoring sprint” or “refactoring period” to “cut some of the technical debt”. The manager and the customer has to choose to invest in refactoring or risk schedule variance.
What’s wrong with this story? The developers clearly have good intentions and the managers make the call. But is this the only choice?
Martin Fowler defined refactoring as “a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior”. I repeat:
Refactoring means modifying the code without changing its external behavior.
Let me ask you this question: How long do you think it should take to stabilize the application when you refactor? Two weeks? A sprint? One day?
The answer is: 0. Nothing. No time at all.
Refactoring really means that a developer takes a piece of code, makes a small transformation, guaranteed to keep functionality intact, and commits the change. When she’s done with the transformation, the functionality is the same but the code structure has changed.
Chances are if you work in a compiled language your IDE knows automated refactorings. If it doesn’t, you must apply the manual method. The refactoring book splits each transformation in a series of small steps that don’t break functionality. While stopping in the middle of a refactoring is not advised because it usually makes the code structure worse, functionality doesn’t change during the process.
My advice to Bill is:
- Ask Joe to differentiate refactoring from redesign and reengineering.
- Define a criteria for done or you risk wasting two weeks. On the technical side, you can look at indicators like cyclomatic complexity, fan-in and fan-out. On the functional side, you can focus to implement the smallest increment that doesn’t fit into the existing code.
- To minimize technical debt, ask Joe to come up with ideas to cut it down as part of the development. Support him in any way you can.
My advice to Joe is:
- Help developers learn refactoring. Practice exercises described at each chapter from the refactoring book. Try a baby steps session.
- Introduce the boy scout rule.
Refactoring is not a separate step. It’s part of the normal development process. Your manager shouldn’t even know you’re refactoring. He knows you’re developing software. You should transform the code continuously, in small steps that keep functionality intact.
And that, my friends, is what refactoring is about.
