How should one deal with technical debts ? Are “refactoring” stories part of the product backlog or not? These are important topics for almost all our customers.
It takes many years of experience to talk about it. Many developers do not work on a code base long enough to experience the impact of their own decisions years later, or they come and experience the consequences of other developers’ decisions and do not take responsibility for their actions.
Refactoring – Not in Product Backlog!
Lately, there has been a lot of commenting on forums and questions at conferences, all about refactoring “stories” in the product backlog. Even if many “technical debts” have accumulated, it is not a good idea to do that. Here is why:
When our project starts, the code is clean. The field is well mown, life is light, the world is at our feet. Everything will be fine.
But when we build new things, we have to drive around the thicket or go through it. Mostly we make a detour.
This inevitably slows us down a bit. To be able to walk fast, we are even less careful than before, and soon even more overgrown thickets have grown.
These new thickets, in addition to the old ones, slow us down even more. We realize that there is a problem, but we are in a hurry to do something about it. We push harder to maintain our early development speed.
Soon it seems that half the code we have to work with is overgrown with weeds, bushes, small trees and obstacles of all kinds. Maybe even old cans and dirty clothes are lying around somewhere. Maybe even a few pits.
Any journey through this confused field of code becomes a long way out of dodging shrubs and leaping over the pits that were left behind. Inevitably we fall into some of them and have to dig outside again. We are slower than ever. Something has to change!
The density of problems is very visible to us now, and we see that we can not just make a quick mow of the field all right. We have to do a lot of refactoring to return to a clean field. We are tempted to ask our Product Owner for time. Often this time is not granted: we are asking for time to fix what we have messed up in the past. It is unlikely that anyone will give up important things for us.
And if we get the time, we will not get a good result. We will clean up everything we see as clean as we can in the time we have. But it will never be good enough. We will have had many weeks to make the code so bad, we certainly will not get that much time right now to repair it. That’s not the way to go. A big refactoring session is hard to sell, and when it’s sold, less comes back than we had hoped after a long delay. Not a good idea. So what should we do?
Very easily! We’re taking the next feature we’re supposed to build, and instead of driving around all the weeds and bushes, we take the time to clear a path through some of them. Maybe we will go around others. We’re improving the code we’re working on and ignoring the code we do not need to work on. We make a nice, clean way for some of our work. And it’s likely that we’ll visit this place again: That’s how the software development works. Maybe this feature takes a little longer. Often not, because the cleanup even helps us with the very first feature that is implemented along the way. And of course it will also help with other features.
Clean, repeat. With each new function, we clean up the code needed by this function. We invest a little more time than we would if we continued to destroy the field, but not much more – and often less. Especially as the process progresses, we get more and more benefits from our cleanup, and the development is getting faster and faster.
Soon, often within the same sprint, in which we begin to clean up, we find that a future feature actually uses the same code range that we just cleaned up before. We benefit immediately from incremental refactoring. If we had been waiting to do it in a big deal, we would have gone the extra mile, postponing the benefits until later, and probably wasting time in places that still did not help.