Technical debt in a software system is introduced whenever you say “yes, I know I should do it that way, but I need this feature now so let’s do a quick-and-dirty thing and shoe-horn it into the system, and we’ll come back later and do it right”. Whenever you say that, and do that, then you introduce a technical debt into the system. You do something that takes a toll, and you owe it to the system to pay it back. Later.
You may think “this technical debt thing, that sounds interesting, how do I get one?”. Well, that part is easy. There are several methods. One of the most popular ones is to create a software system that integrates with other systems, do it well, and then do nothing more. Time itself will create a technical debt in that system. As time goes by and the world moves forward, so do the systems to which yours integrate and as the distance increases, it will be harder and harder to maintain the integrations until one point where they will simply break.
The upside with this approach is that it is very comfortable, in that it consists entirely of doing nothing. The downside is that it’s quite slow.
Another popular approach which needs active work but on the other hand is much faster, is what I call the “AS DAD” method: Authoritarian Stakeholders with Direct Access to Developers. In this method, an authoritarian stakeholder (often, but not always, in the sales organization) will go directly to developers and say that “hey we need to fix this NOW, because otherwise we may lose this deal that is worth dollars”. And the developers, being good-hearted people wishing to help out, they will say the magic words:
“We really shouldn’t push it in like that… But hey, we’ll come back and fix it later!”
Right.
Note that all involved parties in the AS DAD method feel and believe that they do the right thing for the company. They just fail to see the long-term consequences.
In a way, you could say that technical debt messes with time. You see, when dealing with technical debt, it turns out that most often “later” never comes. It’s as if there is a special kind of technical debt timeline, where clocks are stopped as soon as the code is committed. Time freezes. “Later” simply remains “later”, and is never really approached.
And the one pushing the stop button on the clock is of course a New Feature.
When talking about technical debt, I often realize that there are two distinct groups of people. There are those inside the group where technical debt is manifested, essentially meaning developers and the very closest relatives. Then there are those outside this group. These two groups have very different views on what technical debt is, and how we should relate to it.
Those on the inside will typically see technical debt as a really bad thing. It rots the code. It smells. Rot and smell are things that you normally don’t want to have around you. It’s simply not a very nice work environment to be in, and it’s not a good place for producing great stuff.
Those on the outside, they see a new feature. A new and shiny, money-producing feature. New, shiny and money-producing, well those are all nice things. They feel good. And then we might have this situation
- Hey, we got this smell here… um, can we do something about that?
- Um… yeah, so if we spend time on cleaning that up, what new stuff will it bring to the product?
- Eh. Nothing, I guess. It will smell less.
- Nothing, you say? Yeah, OK, I’m gonna go right ahead here and say… no.
- What do you mean ‘no’?
- We will not invest money in something that doesn’t give us anything. By the way, did you get that memo on the new cover sheets?
When two persons, one from the inside group and one from the outside group, talk about technical debt, this type of conversation is not too uncommon. It’s interesting because it highlights some misunderstandings that is appearing between those groups.
The outside group wants features, because features drive income. So when the inside group suggests investing time in paying off technical debt, this appears to be an investment without return. It may appear as if the developers wants to spend time refactoring the code, just because the code will look nice, because it’s fun and because they want to use the latest stuff. And sure, let’s be honest, there might be an element of that involved. But that’s not the important part.
The important part is the piece of the debt analogy that is often completely absent in the conversation.
For a debt to exist, you transfer value in one direction. In what way does value travel in the case of technical debt? You take value from the code. You borrow that value from the code. We could, for the sake of the analogy, say that the inside group is the owner of the code. They are the people creating it and maintaining it. They often feel some kind of responsibility for it. So they take the value from their code and lend it to the outside group, in the shape of a new feature that the outside group can monetize. This is the equivalent of you giving me some money as a loan.
If you loan me some money, I will in return promise to pay them back to you. Later. We do it quick-and-dirty now, but we’ll go back and do it right. Later. So far the analogy holds up. Here is also where the reasoning around technical debt tends to stop. But in real life, there is more to debt than this.
If you lend me some money, you don’t just expect me to pay them back to you at a later date. You will also, and this is especially true if you happen to be a bank, you will also expect me to pay some interest while I am borrowing the money. When, in the end, I have paid you back, I will have paid more than I borrowed. I will have paid the loan back, and some interest on top of that.
The interest rarely makes it into the technical debt analogy. Unfortunately that does not mean that it is not present, because it is.
Let’s say that you have a computer system into which you keep cramming quick-and-dirty implementations of new features, and you keep on doing that at a high pace for some time without ever going back to repay the debt. What will happen over time in that system?
Well, in all likelihood, the pace with which you can keep cramming in new features will slow down, it will become slower and slower until finally one day, it grinds to a halt. Not a screaming halt, because right before the halt things will go so very slow.
If the pace at which new features can be added goes down, that means that the time spent for each feature has increased. And that means that the investment needed for each feature has increased. If we had a “dollars per feature” measurement, that curve would steadily rise over time.
There is a word for this: interest. This is the interest that we pay on the technical debt. As we keep borrowing more without paying back, the cost of the interest will rise. It’s the technical equivalent of just getting new credit cards because the old ones are maxed out.
And this is why, just as in financing, paying back the technical debt is crucial for sustainability in the long term.
