Sometimes I make mistakes. One of them was when I commissioned what I now affectionately call the Refactoring Branch of Doom. Doomed because it was never ending. The refactor was too big and, because it was done in a branch away from the main code base, the refactoring guys never caught up with the main development team. So I canned the doomed refactoring initiative and we did it a different way. One that worked.

Background

I had a team using emergent, code first, design. After a while, with the new people piling on, the code was a bit of mess. So we decided to refactor to address some of the technical debt. A couple of the senior developers volunteered to do the refactoring in a branch. Estimate: 4 days.

Refactoring Branch

Some weeks later the refactoring team were still not done and the estimate was still “4 more days”. It was obvious to me they were never, ever, going to finish. The problem was the branch.

The main development team were busy working on new functionality and checking their changes in. When the refactoring team had finished a batch of refactoring they then had to do a reverse merge. This in turn instigated another round of fixes to catch up. And once they’d done those fixes they found that trunk had moved on again. So they needed to do another reverse merge. Etc.

Refactoring Branch of Doom

The diagram doesn’t show the full story as the refactoring team did manage to do one merge into trunk at about two weeks. It delivered some benefit but not the whole thing and that last bit was the problem. The 80-20 rule again.

We did it a different way

It was obvious to me, although not to everybody, that this refactoring would never catch up to the main development team. So I canned the initiative. And did it a different way.

First of we cherry picked a few goodies from the refactoring branch and merged those into trunk. Took a couple of days. And involved accepting that the bulk of the four weeks work would be thrown away.

Then we delegated the refactoring to the development team. The key aspects of the new approach were:

• Everybody refactors
• Small refactors
• Close to trunk

The developers fixed issues in their area of the code as they worked on normal User Stories. As new functionality was built the associated code going into trunk was clean of technical debt. This took a bit of tender loving care from the Technical lead and one of the guys from the refactoring team.

One of the big wins for this approach, rather than a dedicated refactoring team, is that the problems did not recur. The whole team knew what the issues were and how to address them. So they just did it.

The surprising part of this story is that it took the team only two weeks for the refactoring to be complete in trunk. The refactoring wasn’t obvious because they were also building functionality. But at the end of the two weeks the code was clean.

I learnt my lesson on that one. Collective code ownership + small refactorings + close to trunk.