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?

Continue reading “Refactoring Keeps Functionality Intact”