Not on the backlog: a response

Ron Jeffries recently wrote a great article in which he recommends how teams should dig their way out of thickets of technical debt:

We take the next feature that we are asked to build, and instead of detouring around all the weeds and bushes, we take the time to clear a path through some of them. Maybe we detour around others. We improve the code where we work, and ignore the code where we don’t have to work.

I wholeheartedly agree with this approach, and with the advice and analysis in Ron’s article. Ron says “Simples!” but I don’t agree. For most team there are a few significant hurdles to overcome:

The team has to recognise the situation it is in, and that a new approach is required henceforward.
The team needs to discover the courage to take the time to invest in this change of approach.
The team needs to develop an understanding of what better code looks like.
The team needs to learn how to create better code out of bad code.

None of these things is trivial. All of them require the whole team to go on a journey, probably to learn new skills, and above all to have the courage to make the change.

Don’t put refactoring stories on the backlog. Instead, invest in learning what habitable code looks like, how to write habitable code, and how to improve the habitability of existing code. That’s what will make you go fast; that’s what will get you out of the thickets.