Questions about how to measure technical debt were on the minds of computer scientists such as Miehr Manny Lemmon as far back as 1980, when he said: “As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it.” The actual term was coined by software developer Ward Cunningham in 1990, who said, “Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt.”
Technological advancements in the forty-plus years since have made development much more complex, and the inherent challenges grow along with the scope. One reason for technical debt is due to the rapid move to remote work after the pandemic. This brought on a mixture of technical debt including security and infrastructure processes, which created a need for more accurate technical debt measurement for decision-makers. This blog dives into the concept of technical debt and effective ways to measure it, to give developers some insight into how to avoid it in future projects.
For deeper inquiries, you can always contact Foghorn Consulting and speak to an expert if you prefer to ask about managing technical debt directly.
What is Technical Debt?
Technical debt describes the cost that companies incur when they take the quickest solution to a challenge, rather than the ideal solution that would take longer. In development, the quickest solution refers to allowing unoptimized code as part of a release. This isn’t to put a negative view on expedient releases, but to be aware of the amount of work that will need to be done later.
Considering this debt helps developers decide where the balance is between speed and polish, so they can find the balance between the two. There are some scenarios when speed is of the essence–such as beating the competition to market with a game-changing feature. If being first brings enough benefits, a development team might simply take it on like any business taking out a loan they’ll have to make up with future work. In this regard, technical debt is a tool that developers can use to gain a better understanding of when to release and when to go for another QA round.
How To Measure Technical Debt?
Knowing how much of a commitment is required to fulfill any measure of technical debt is the only way to decide if it’s worth the toll. Turning the abstract into clearly-defined technical debt metrics is how it becomes a decision-making tool instead of a source of concern. Consider these examples of technical debt measurement to understand how one might calculate it:
- Technical Debt Ratio (TDR) – As its name probably indicates, TDR is probably the most common metric used to measure technical debt. This is an overarching metric that considers the total impact of others like those mentioned above, and puts them into a number called “remediation”. Remediation expresses the cost to fix a system. This is considered against development cost. Most expect operational TDRs to be in the single digits, though this is not an end-all measure. Remediation and development numbers can represent lines of code, hours, or money, so long as the same is used for both: TDR = (remediation/development cost) * 100.
- Cycle Times – This is a measure of the period between when a section of code is committed, and when the results are deployed or published. It is one of the most straightforward measures to calculate technical debt from a production perspective. In fact, cycle times are a common measure for productivity in any operation that produces a product. If cycle times are too long during updates, chances are high you’re seeing the result of technical debt.
- Code Quality – This combines several more specific calculations into a single measure, which is used to compare the quality of each iteration of code. Standard of quality can be expressed by simple, common sense indicators like lines of code, inheritance, and coupling, but also those that are their own metrics like code complexity. Decreasing code quality is often an indicator of technical debt.
- New Bugs vs Resolved – Another straightforward indicator of accumulating technical debt is the amount of bugs that are being created versus the amount being resolved. Based on inherent software entropy, we know that some bugs will get introduced with each release, but these should be overwhelming the resolved bugs.
Finding Help To Lower Technical Debt
Since most work-related metrics are really just a measure of how much time you can spend, any measure that increases efficiency can have a positive impact on minimizing and eliminating technical debt. Fast-paced agile development should be especially familiar with the cost of expediency, so managing the surrounding infrastructure is a concrete first step you can take before restructuring.
For cloud-based infrastructure, Foghorn Consulting provides this in the form of FogOps, our highly-tuned version of DevOps. For developers who want to instill the most efficient form of CI/CD in the cloud, or those considering migration, consider these managed services to expedite the development process:
