Technical Debt

What is Technical Debt?

Technical debt is a metaphor originating from the monetary debt analogy. It refers to the extra development work that emerges when software engineers choose easy, yet less-than-optimal solutions. Such shortcuts are often the result of working under pressure or due to technical limitations present during decision-making. 

As an engineering leader, one of your challenges is to explain sometimes dense technical concepts to non-technical business executives. The concept of technical debt was born of that challenge, when Ward Cunningham used a financial metaphor to explain to his boss the purpose of the refactoring his team was doing – to avoid paying too much interest on a “loan.” Today, we still find ourselves trying to explain these concepts. While the concept of tech debt identifies a real challenge that software engineering teams struggle with, many engineers still disagree on the actual definition of it.

How you define software technical debt to your executive team can have serious impacts on the projects you prioritize and resource allocations. But tech debt can be very company-specific, dependent on the culture, who has a greater share of voice, and many other things. We wanted to understand the different ways people think about tech debt, so we asked VPEs from different walks of life. Understanding these different perspectives can help you come to a definition of your own that works for you and your company. Here are some of the explanations they gave us:

Types of Technical Debt

Good Technical Debt

At Crayon, VP of Engineering Jack Walter abides by a popular notion that there are both bad and good kinds of tech debt. With that in mind, he explains that “having joined after Crayon has already been building product for 2-3 years, there is obviously a large amount of tech debt, some good and some bad. What I try to focus on is evaluating the instances on a case-by-case basis, paying down the ‘bad’ debt that is restricting our growth, and doing our best to only take on ‘good’ debt going forward.”

Technical Debt as a Strategy for Speed

VP of Engineering Rob McDonald explains how at Zaius, tech debt is used strategically, and is intrinsically linked to the health of the business and sales organization. “Tech Debt are the things we do sub-optimally (intentionally or unintentionally) in order to accelerate our delivery. When sales are booming, we’re more likely to pay down debt since there’s (often) less urgency to have new features. When the Sales team needs a boost via feature or a product change, we incur debt to go faster.”

Balanced Technical Debt

Jellyfish’s own VP of Engineering, Eli Daniel explains the balancing act of taking on technical debt. “I think of tech debt as work that needs to happen eventually, but that we choose to put off until later in the interest of speed today. Extending the personal finance metaphor of taking out a loan to get money now, but at the cost of paying back even more later: it’s important to be thoughtful about how much debt you take on, and at what terms. On our team, we’ve been pretty disciplined all along, so we’re more in the mode of making our planned monthly mortgage payments that we knew about going in vs scrambling to get out from under crushing credit card debt. Concretely, that looks like having pragmatic discussions about how far to take things, how to balance speed of delivery today with removing the messes that will slow down innovation tomorrow, and being willing to both take the extra time to make things sustainable when it’s needed but also being willing to live with systems that aren’t yet living up to their full complete vision.”

How to Measure Technical Debt

For most engineering organizations, you’ll almost certainly want to measure it, figure out the right amount of time and resources to devote to it, and make sure your organization is allocating a proportionate amount of work to it. Until you have a clear definition of what tech debt means to your company, that may not be feasible. 

The Causes of Technical Debt

Technical debt in software product development and management can be daunting. Just as with financial debt, delaying necessary payments or “code maintenance” accrues interest in the form of additional work, often much more than if addressed promptly. 

To break this down further, consider an example of technical debt. Imagine a team hurrying to meet a project deadline. They might implement a faster, less optimal solution instead of the initially planned method. The immediate goal is achieved, and the product is delivered. Still, they have created a technical debt that will need to be returned to improve software efficiency in the future. 

Diving deeper into the causes of technical debt, you should understand that it is not inherently bad or always avoidable. Technical debt can fall into two broad categories: 

Deliberate debt is accrued intentionally, often under time pressure or resource constraints, as in the example mentioned earlier. 

Accidental debt occurs when new methodologies or technologies emerge, making previous approaches obsolete or less efficient. 

Translating this concept into a technical debt from a Scrum perspective, Scrum’s iterative nature means teams often have to make trade-offs between optimal solutions and practical timelines. Continuous delivery might result in compromises on code quality, generating technical debt. 

Mitigating and Reducing Technical Debt

Technical debt is essentially the compromise that developers often have to make. While it may contribute to expedited project timelines, the repercussion is often a more complicated and costly software maintenance process. 

Software managers often grapple with high amounts of technical debt, which may impact the quality of a software product. More so, it results in:

• Delayed updates
• Product failures
• Customer dissatisfaction

These factors underline the significance of technical debt management. It is a pivotal facet of product strategy that every engineering leader must master to ensure consistent product quality and business continuity. 

One substantial approach to mitigating and reducing technical debt involves early identification. Recognizing problematic code or design elements right at the development phase can prevent the accumulation of technical debt. Incorporating robust testing protocols can rapidly diagnose issues that may snowball into major challenges in the future. 

Timely detection, followed by regular refactoring of the code, is a potent tool for technical debt. On the other hand, technical debt should not always be viewed in a negative light. Indeed, it represents a trade-off, a strategic decision taken amid time constraints or resource limitations. 

Technical debt vs maintenance is a constant interplay that engineering leaders need to balance to deliver timely solutions without compromising long-term software robustness. However, they need to manage this interplay effectively. Limiting the creation of new technical debt while charting out clear strategies for reducing existing debt can elevate quality, speed, and efficiency. 

Active debt management strategies such as dedicated debt reduction sprints, automated code review, promoting reusable designs, and even cultivating a team culture of high coding standards can prove to be transformative. By shedding light on the aspects of technical debt and proposing viable solutions for its management, engineering leaders can transform this perceived liability into a strategic asset. After all, successful technical debt management is a powerful testament to responsive leadership and strategic agility.