Refactoring Keeps Functionality Intact


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:

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.

Add comment Reflections on design, craft and software

A new home for merging ideas about design

It is my strong belief that software design can learn a lot from other design disciplines. I wrote blog posts, a book and did talks on this topic, and it was time to group them all together. These ideas have now a new home: My plan is to add more blog posts there, and to involve other people doing work in this area.

Read My Book “Usable Software Design”

How UX techniques can be applied to software design to develop software better (given that the developer is the user of software design).

Read My Book “Coderetreat Hosting And Facilitating”

Learn how to facilitate and host a coderetreat from two of the most experienced coderetreat facilitators.