Technical debt has varying definitions, but at its simplest, it relates to the cost of additional work or rework of code and other assets during software development. It’s much like credit card debt; if someone makes a big purchase and does not pay it off soon, interest accumulates and can spiral out of control. Until addressed, elements of technical debt — such as a bug that has not been adequately fixed — will continue to accrue interest.
While technical debt is hard to avoid altogether, its mitigation is important. Teams may spend more time on it — such as sorting out vulnerabilities that have only just been discovered — rather than creating new code. It is also a security risk. Complex codebases that have become unwieldy are more likely to contain the kinds of vulnerabilities targeted by attackers. Technical debt also contributes to the rest of the organisation viewing IT as an overhead cost rather than as an ally and asset.
Paying it forward: why APIs are key to easing technical debt
The causes
There are multiple common causes of technical debt. They are often the result of taking simple or fast short-cuts in a project instead of taking a more sustainable approach. Some of these causes are cultural. For instance, a team may be under pressure to release a product to market before it is ready, leading to more changes needed later. Similarly, if a project is not sufficiently defined before development starts, that can lead to considerable rework later.
Mergers and acquisitions can exacerbate technical debt, thanks to legacy codebases that must now interact, or are longer be fit for purpose. We all know, however, how difficult it can be to upgrade outdated platforms and systems.
Lack of technical skill may be another cause. Yet another is not investing enough time and effort in developing robust code testing strategies. Spending too much time on manual testing or deciding to skip specific test processes can contribute to this issue.
Fixing technical debt
There is no single silver bullet that will fix technical debt. Instead, it needs to be addressed in a multi-faceted way. First, there needs to be a better cultural understanding across the entire business regarding precisely what it is. Importantly, stakeholders, including product owners, must also understand how their actions and decisions may be contributing. Going back to the credit card analogy, it helps if stakeholders can bear in mind that they could be dealing with 22% or higher annual interest. In such a case, the temptation to ‘spend’ beyond the team’s limits and live with minimum payments is less tempting.
To pay off existing architectural and other types of technical debt, teams should compare their current minimum payments and the impact of those on overall velocity and team morale with the staggering expense of re-architecting part or all of a solution. Moving from a monolith to microservices is a good example. As mentioned, however, there is no one-size-fits-all solution. Long-term maintenance and ‘expenses’ need to be considered as well. For instance, it might be easier to migrate just the most troublesome part of a monolith to a microservice to pay off the ‘credit card’ with the highest interest rate.
Current software development practices can help to reduce technical debt. DevOps, DevSecOps and Agile all have a role to play here and, of course, can co-exist with each other. Each of these practices, when executed well, strike a balance between time-to-market and software quality. Plus, they help break down the cultural barriers among different teams. In turn, this can make technical debt easier to surface and prevent or, at the very least, drive strategic decision-making around when to incur technical debt. Clear communication between everyone is vital when deciding what to prioritise in the software development backlog.
Agile drives business growth, but culture is stifling progress
Visibility and traceability
Likewise, better insight into everyone’s activities, planning, and whether a project is still on track will help spot technical debt. Requirements and traceability management both have a role to play here, and can include tracking whether standards compliance is being addressed earlier rather than later. Making sure that software is compliant from the get-go will help reduce later rework.
Automate testing and monitoring
These days, automation of testing and monitoring are essential to eliminating technical debt, particularly with large-scale or complex codebases. Traditionally, manual testing and detecting defects can slow down time-to-market, but conversely, allowing vulnerabilities to escape into production creates technical debt further down the line. So, automated code reviews, static code analysis, and ‘shift left’ testing, whereby tests are carried out earlier in the process by developers with minimal effort, all help keep a lid on technical debt. Furthermore, codeless, AI-driven testing means that more people can be involved in testing throughout the software development lifecycle, reducing dependency on QA managers’ time and expertise.
Technical debt is a fact of life for most organisations, but it does not have to become untameable beast. By tackling it on multiple fronts, an organisation can reduce the drain on team speed, keep teams motivated, and improve performance.
