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 then 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 fails to pay back the debt they just 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 and so on. This becomes a vicious cycle that is very hard to break out of.
theagileexecutive.com/category/technical-debt
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. The team learned from previous mistakes and believes that 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 and soon enough we will find ourselves facing the same issues again. Yes there are tech stacks that make it easier to code and test than others. But the real problem was due to 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.
1. theagileexecutive.com/category/technical-debt
