For the longest time, I’ve had a massive issue with technical debt. Every single project I’ve ever been working on have had the magical black box they dump a new thing into every 3 months. “Technical debt” we call it. Realistically we should be calling it technical risk, as that is really what is it. It signals exactly what it is, but it just doesn’t work.

But then again, technical debt doesn’t work either. It’s just one of those things that sneak up on you and suddenly consume everything and end up having a life of its own. It becomes one with the project.

Usually you start up a project, develop it to a certain point of a release, you release the product in whatever state it is in and continue your development cycles. As the project grows, you hire new developers and all of a sudden you realize that you’re actually delivering even slower than before.

Thus you end up sitting down and look at solutions, What if we implement SCRUM, by-the-book? What if we hire more Senior Developers?.

All of a suddenly everything slows down even further.

Lets try to use kubernetes?

All of of a sudden the product doesn’t even work anymore.

The CTO steps in and comes with a brilliant solution, coming straight from his LinkedIn feed. 20% of each sprint has to be spent on reducing technical debt. Everyone has been doing nothing but complaining about technical debt, so now they’ll get 20% each week to solving the problem.

The team is over the moon, but they’re facing a different kind of issue now. It was already super tough trying to estimate tasks in a realistic manner and now they have to account for another 20% of your total time being spent on technical debt? Next planning the team accounts for everything. 70% of the time gets spent on product development and 20% of the time gets spent on technical debt, most of which is currently awaiting analysis, but you know, the 20% total time can probably cover that too.

Next week hits and 2 major high priority bugs come in. The bugs require immediate fix, so the team decides to cut down on technical debt to 10% to cover the time spent on bug fixing. Unfortunately the product development was underestimated, so the team couldn’t finish the sprint goals in time; so unfortunately to finish the sprint goals, the time must be taken from the remaining 10%.

Next sprint we’ll up it to 40%

Obviously this doesn’t happen.

We’ve reached a point in software development where we come to the conclusion that time is the ultimate problem solver to technical debt. It’s like a quick loan debt that just gets paid by the start of the next month. While it is definitely true to a small amount of the technical debt out there; but for the majority of it, technical debt involves large risks, incomplete business logic or massively complex design and a complete lack of backwards compatible safety.

When you need to solve technical debt with time, then the time is not worth much if you’re not accounting for this from the start. On the other hand, it can also create an illusion that you’re attempting to solve the issues and if you’re unable to successfully solve the issues, then it must be the individual teams at fault.