The first rule to reduce technical debt
An extended version, beyond the limit of 140 characters, of an interesting discussion
Today I posted this on my social accounts:
The first rule to reduce technical debt is: you don’t create technical debt.
It’s a bold statement, clearly made to be provocative and compel people to think, comment and argue about it. As expected, it has sparked many reactions and heated discussions.
But that was my intent (not just for the sake of igniting a flame). I wanted to see how my words would be understood and interpreted by people. Because everything here is about the words.
There are three keywords in that phrase. The first one is ‘reduce’. The second one is ‘technical debt’. And the last one, the most important for me, is ‘you’.
Reduce
Let’s start with the first one, which was misunderstood (at least, looking at the comments).
This is the premise of all the argument: if you want to reduce the technical debt. There is an ‘if’ so it means that you want to, there is a commitment or an agreement for that. Whatever the reason is, this means it’s a problem, something you want to/have to work on.
Not only: it’s about the reduction, so there is already an existing amount of technical debt. So we are not talking about the ‘creation’ of technical debt (this is the suggested solution, but we’ll get to that in a moment) but about a possible solution to cut back the existing one.
If you have come to the conclusion that you need to reduce it, it means it has become a problem, a burden to minimize. That’s my hypothesis here.
(Le me be clear. It’s absolutely acceptable, I would say physiological and healthy, to have technical debt in a software project. I think the complete absence of debt would be a symptom of some kind of dysfunction.)
Technical debt
The second keyword is the one that heated the discussion. For two simple reasons.
First of all, because everyone has its own interpretation of what “technical debt” means. It has a very broad meaning since there is no definition of what ‘technical debt’ is. That’s absolutely subjective and depends on the context (read the comments to my posts, for that).
One of the most used counter-argument has been: “If you are a startup technical debt is a good thing. Otherwise, it means you’re not being pragmatic enough, you don’t ship fast (or ever), you’re too slow to the market.” Who doesn’t agree with that? As I pointed above, technical debt can be healthy or even looked for in order to have a working business.
But that was my little trick here: to use this generic word in this way.
Think of it: if you call something ‘technical debt’ this means you can recognize it, you have somehow an idea of what it is. And if you want to reduce it, also of why you want to do it, what are the problems that it’s bringing. So, stopping to add new technical debt on top of existing technical debt isn’t one of the simplest ways to reverse the trend? How can this idea be so contentious?
Well, there is another reason why I think it triggered a lot of reactions: because it appeals to our own experience, our bad memories of messy codebases, even our self-esteem (“What? I am not the one that creates technical debt! I am a good developer.”) and so we tend to interpret/filter/bias the phrase through these lenses.
And this leads to my next point.
You
The last keyword, the one that I consider the most important, was also the one that went unnoticed.
It’s been decided (you or your team has agreed) that the technical debt has become a problem, and needs to be reduced. Then why things don’t improve? Why?
Well, because of you.
Yes, you. Really, I mean you. You who are reading these words. It’s your responsibility, your duty to stop adding new technical debt.
If you want to decrease your technical debt, stop adding new technical debt in the first place. Apparently quite obvious, I know, but that’s the whole point of the discussion here. (Again, if that was the decision. That’s the premise, of course).
But everything starts with you. Not with your colleague(s). Not with your team. Not with the good principles and best practices saved in a wiki page or printed on a wall.
If your codebase is filled with technical debt (usually cut-corners and will-dos, but that’s not the point here) it’s because someone has “put it there”. It’s not that one day magically it appeared. Or that someone or something added it for some reasons, overnight, little by little. That technical debt it’s there because of you (ok, not only you, but that’s not the point I want to make). You have decided that there was not enough time to make something properly. Or that fixing that problem immediately it would have required too much hassle, so you have just opened a new ticket. Or that the code you wrote, at the end of the day, was working so why bother to find a better way to implement it.
We tend to think that the solutions to the problems rely on something that is exogenous, external to us. A tool, a process, a list of good intentions, a mutual agreement. Something that regards everyone, and so at the end no one. Especially, not ourselves. Not you.
Things don’t change if you don’t change.
(And just to be clear: that ‘you’ it’s not only you, it’s also me).
Conclusion
Now, try to re-read my sentence, and put the stress on the word ‘you’:
The first rule to reduce technical debt is: you don’t create technical debt.
How does it look like? How does it sound? Makes more sense now?
Can you understand what was my point now?
Addendum: my badge of honor for all this story is this:
I don’t know if his ‘like’ is because he agrees with me or because he just wanted to encourage me (“oh, poor kid”). In any case, it made my day. Thanks, Jacopo.
This blog post has also been published on Medium.