The Vicious Cycle of Technical Debt

In my previous post, we looked at the difference between good technical debt and bad technical debt and highlighted the importance of keeping our debt low. Unfortunately, the typical scenario that most teams face is that they eventually reach a point where their output is lower than what it used to be.

Instead of stopping and addressing the reason for the slowness, the team is put under relentless pressure to deliver more. To do that, the team ends up taking on more technical debt. And because of the pressure, the team is just focused on delivering features and ends up failing to pay back the debt they’ve incurred. So the technical debt accrues on top of the existing debt. As a result, the team is further slowed down and fewer features are delivered. The team is put under more pressure to deliver so the team takes on even more debt. This becomes a vicious cycle that is very hard to break out of.

Eventually, the product becomes unmaintainable and headed to bankruptcy or, in software terms, a complete system re-write. But this time, the re-write comes with a team promise that we learned from our previous mistakes and we won’t end up here again because we are picking the latest and trendiest tech stack. However, the problem was never a tech stack problem. Yes, there are tech stacks that make it easier to code and test than others. But the real problem is not having a proper technical debt management plan.

In my next post, we will see how to actively manage our technical debt and in turn avoid getting into this vicious cycle.

The Vicious Cycle of Technical Debt is the fifth in a seven-part series on Technical Debt from Excella Software Development Lead Fadi Stephan.

Part 1: Top 4 Symptoms of Bad Code

Part 2: Top 5 Reasons Writing Bad Code Happens

Part 3: What is Technical Debt?

Part 4: Good Technical Debt vs. Bad Technical Debt

Part 5: The Vicious Cycle of Technical Debt

Part 6: The Technical Debt Management Plan