“Look, it’s critical that we meet our deadline, and I know that we are already running behind. So please, we need you to push faster no matter the costs. And I don’t care if you need to cut some corners on the way. I’m totally aware of the costs, we just need to meet the goals for the deadline and after that we will have more time, to go back and fix what’s needed”
Sounds familiar?
Funny enough this kind of conversation have been happening to me on many of the projects I’ve worked on, usually on several occasions. And to be frank, I totally understand where this is coming from, and I’m also aware there are times in the life of a product that this is exactly what needs to be done.
What I did find is that, even if stated otherwise, many seem to be quite unaware of the real costs involved in such a move. So let’s try clearing those up a little.
Technical Debt – Will hit you 3 times
The first time you get hit by technical debt relates to the subtle fact that organizations usually like the reckless speed a technical team can go at. Once the team stop doing many of the things that needs doing, suddenly, everything seems to be going much faster. And after a few weeks of showing an increased productivity, everyone starts believing that this what we should expect.
Wrong – what actually happens while we are working in such a way is that we are digging holes, and when you find yourself in a hole, first thing to do is to stop digging. That is, the first thing the team needs to do is get back to working the way it should and do everything that needs doing. Still, from the outside, the perception is that suddenly everything is slower. Even though we are just back to normal pace.
Try it next time you watch a talk on YouTube. Increase the speed to x2 for 30 seconds. Revert the speed to normal. It now feels that the speaker has some speech impediment. But the impediment is actually with the viewer, who needs to readjust to normal speed.
Technical Debt – will hit you 3 times
The second cost involved, is the one that many grasps as the only cost. The cost of going back and fixing what needs to be fixed. You took a loan by skipping out on a few things, you need to pay it back and do them, it’s as simple as that. If, for example, you didn’t write test automation for new code, you need to go back and write it.
Technical Debt – will hit you 3 times
And last, but not least, is the “interest” involved. Like any type of loan, a technical debt also incurs an “interest”. Yes, once you start cutting corners and compromising technical standards, more mistakes tend to creep in and over time the need for dealing/fixing those things will also take an extra cost. For example, let’s say, that for the sake of speed, a piece of logic was duplicated instead of properly refactored to a single shared place. Now, every bug or change in that logic needs twice the effort to get done. Not to mention the chance that someone may forget to fix both places and now you get another new bug to deal with.
The Numbers
Ok – so 3 times, what’s the issue with that? It’s just going to cost me a little more, I probably won’t be able to notice it anyways.
Let’s try looking at some numbers. Let’s assume that for a period of 8 cycles (weeks, sprints, months or whatever) the team has decided to take a loan of 10 “units of work” which allows them to go 10% faster (again it can be days, hours whatever). And let’s take the number of 10% as our interest rate.
Side note – Some may argue that 10% interest number is too high a rate. Personally I think its quite a conservative number.
Here’s the table showing the loan performance over these 8 cycles:
Cycle 1 2 3 4 5 6 7 8
Total Debt . 11 23 36 51 67 85 104 126
Note – after just 8 cycles, the interest alone (46 units), is going to cost about half of the base loan amount (80 units – 10 units per cycle).
Ok now what? Now comes the hard part of deciding how to pay back this debt.
One strategy is to just stop everything and pay the debt. In our example, it will take about a cycle and a third. Since the overall capability is 100, in one cycle the debt will drop to 25, add the interest to that, and we need almost a third of the next cycle to pay the rest.
However, in most contexts, that’s not something an organization will do. Stopping everything is not an option and there’s a need to repay the loan gradually over time (like most other types of loans). The underlying logic usually goes like this: If we got a 10% increase in speed over these 8 cycles, let’s go 10% slower and after 8 cycles the debt will be paid.
Sadly, it’s not that simple. First, 10% slower from the current state just bring you back to normal pace (first hit). So actually, in you want to pay 10% of the debt, from the organization perspective, it will feel about 20% slower than current state. Second, since now the overall debt is 125, the interest alone (third hit) is more than the payment itself of 10 units.
Actually, in order to close the original debt (second hit) in about 8 cycles, you need to pay 20 units per cycle (30% slower from organizational perspective, compared to current speed) and then the debt left will look like this:
Cycle 1 2 3 4 5 6 7 8
Total Debt . 116 106 95 82 68 53 36 18
What does it all mean?
Not much. Mainly it means that taking a technical loan is a risky business, and it helps to be fully aware of the implications of doing that. Be aware that a 10% speed increase, implies that you will need to go ~30% slower for about the same amount of time. Be aware even that is assuming you don’t do it for a very long time, otherwise interest tends to explode:
After 11 cycles in our example the overall debt reaches over 200 and going 30% slower pays off just the accumulated interest alone.
And finally, while crunching numbers is always fun, in a real context, you usually don’t have the ability to control or even quantify the debt you are actually taking. In addition, in contrast to a loan from the bank, with technical debt you don’t get a balance sheet, or a forecast of the accumulated debt. You don’t get to see the real interest rate either.
When the team is told to run, they run as fast as they can. It doesn’t take that long time reach the point in which just paying “interest” causes a reasonable team to feel like it’s going in circles. Whenever you can give your team enough slack to prevent unintentional debt from creeping in. and pay your debt as early as possible.
