Organizations create technical debt when they prioritize a low-cost, faster development approach over the conventional development lifecycle. While it may be rewarding in the short-term, it is certainly not in the best interests of the organization in the long term. Moreover, organizations with accumulated technical debt only consider addressing it periodically and pay little heed unless fixing issues become emergent. While the industry has no agreed-upon metric to grade a system for tech debt, certain reliability and velocity cues start showing up over time, ultimately impacting running costs.
Why is it called debt and not a risk/issue?
The 'debt' incurred as part of technical debt is often the time tradeoff for doing something right versus the shortest path to Minimum Viable Product (MVP) through the product's lifecycle. Technical debt accumulated over time inflates 'Run and Error' budgets, besides impacting the longevity of platforms that must be recoded to be compatible with newer technologies. Some industry leaders believe that this debt is like a risk, but when this risk materializes, it becomes an impact, so it is essential to address it sooner than later.
Five myths about technical debt
Here are the five most common preconceived assumptions about technical debt that limit early action:
- Technical debt is all about code quality and dependencies.
While code quality impacts the maintenance of the product, elements like architecture, design, and infrastructure choices also significantly affect the time-to-market.
- Latest frameworks/technology help organizations stay free of technical debt.
Organizations often assume that by running the latest version of the coolest framework or transitioning from monolith to microservices, they no longer have any technical debt, but the reality is quite different. A lot depends upon the technical infrastructure of the organization. Within most organizations, there is a significant interdependence between systems that compounds the problem of technical debt and affects the platforms' reliability.
- Technical debt is bad.
If used correctly, technical debt can accelerate product journeys. However, what is important is addressing the technical debt as soon as possible post the MVP stages to ensure a better ROI. Debt accrued initially can be offset by velocity gains to remediate and make prudent design decisions.
- Technical debt only impacts the software engineering community.
Organizations often assume that the impact of technical debt is merely limited to the software engineering community, and they can build workarounds to address the issue. For instance, when a truck's tires start wearing off, other parts like fixtures and springs also start degrading parallelly. Similarly, as technical debt starts affecting the tech teams, fatigue also sets in for the support organizations and product owners, and overall resiliency-related issues increase.
- High-level DevOps adoption and forward-thinking saves organizations from tech debt.
In many situations, DevOps adoption with dependency and design issues counteract the benefits to velocity due to bloated software, accelerating technical debt symptoms and visibly impacting the product.
In a nutshell, it pays off for organizations to accept that the systems in question might have technical debt and take measures to avoid a potential increase.