Technical Debt: Causes, complications, and how best to correct for it.
Debt can be diabolical.
Not because of what debt is, but because of what it can become. And for leaders in the IT space, technical debt is no exception.
Coined by Ward Cunningham, Gartner defines “technical debt” as what an organization must spend on digital technology to continue operations. This term is specific to software engineering, design, and development (i.e., DevOps). The term itself has evolved since its introduction in 1992—and it would be an understatement to say the associated stakes have evolved as well.
As of 2022, IT decision-makers around the world reported that resources devoted to clearing technical debt rivaled that of short-term investments, sustainability transformation, and digital transformation initiatives:
Those are sobering figures, and not simply due to the sheer amount of capital they equate to (i.e., 15%-60% of every dollar spent on IT, according to a 2022 study by McKinsey).
It also stands as a formative hurdle for chief information officers (CIOs) who are increasingly tasked with improving customer experience and leading digital transformation.
So, what’s causing all this technical debt within modern enterprise businesses? Left unmanaged, what sort of damage can it cause? And, most importantly, how can IT leadership (CIOs, VPs, and chief technology officers (CTOs)) begin working to “pay” their own organizational debt?
Let’s start with the basics.
Major causes and common categories of technical debt
Cunningham’s metaphor makes for more than a shallow comparison—technical debt (or “tech debt”) accrues forms of “interest” over time, exactly as financial debt does. Both forms of debt are also largely unavoidable to some extent and commonly result from workarounds and suboptimal reactions to business needs.
Major causes of technical debt
For technical debt, response quality to business pressures typically boils down to short-term vs. long-term thinking. Of course, in an ideal world (one with unlimited time, budgets, and uber-magnanimous management) short-term thinking wouldn’t be necessary.
However, the ever-present realities of deadlines and targets often force even the most future-minded development teams to employ “quick fixes” that they’ll need to revisit down the road.
Lack of employee training and overall knowledge are also factors that contribute to technical debt. Teams don’t know what they don’t know, meaning best practices and more efficient solutions may never make it to the table. Despite hard work and best intentions, these deficiencies can result in suboptimal code quality and inefficient prioritization of maintenance tasks.
Legacy code can also play a role here, as teams may lack the knowledge base that was present when critical software was implemented. Or, they simply may not have the skills or experience in the kinds of testing needed to keep the code base of a legacy system working and bug-free.
And while legacy code certainly contributes to making code debt one of the most common categories of technical debt, other contributing factors to bad code can result from failures to meet and maintain best practices and high standards.
Factors here include the pacing of release cycles, insufficient testing and code reviews, outdated dependencies, and, again, an emphasis on short-term goals and thinking.
Common categories of technical debt
Much like the relationship between coding best practices and code-related debt, other common categories of technical debt are directly related to their primary causes.
In addition to code debt, these include the following:
Documentation debt: Similar to the effects of inheriting legacy code, this form of debt plagues teams that aren’t supported with adequate and up-to-date information. Documentation debt weighs especially heavily on new hires, who lack a comprehensive understanding of the codebase.
Infrastructure debt: This debt category happens due to issues with an organization’s underlying software infrastructure. While legacy systems can contribute to infrastructure debt, additional factors of this category may be due to lax or outdated security measures, complications during system migrations to the cloud, and insufficient automation solutions.
Design debt: Not every DevOps team inherits a system. Some build them from the ground up. And design debt can occur due to problems overlooked or inadvertently engineered into a system’s software architecture. These problems typically relate to compatibility, scalability, or the system’s ability to accommodate necessary features.
Dependency debt: An analog to the impact documentation debt has on employees, dependency debt occurs when an organization’s software has to rely on depreciated and/or outdated libraries, platforms, or packages. This category of technical debt can result when different parts of a system use incompatible licenses or when the interdependencies between system components are overly complex.
Testing debt: In our opinion, testing debt is the last major category worth distinguishing here, and it refers to insufficient testing for the code. Due to time or resource constraints, or a simple oversight, a lack of unit, integration, and functional tests make bugs harder to catch and fix, leading to exponential defects.
Here’s a final, important note related to debt categorization. As you now understand, there exists a large amount of overlap between these different types of technical debt. That, and specific definitions of technical debt can vary.
However, as causes, their cumulative effects on how a business is able to function tend to be consistent.
The risks of letting tech debt accumulate
As we shift to covering different ways technical debt can impact business function, remember the goal of having no amount of technical debt simply isn’t feasible.
Tradeoffs are ever-present, between temping shortcuts and long-term thinking, between advocating for high-quality code and delivering on what needs to be done “tomorrow,” etc.
It’s a balancing act. However, that balancing is easier to manage when you understand and appreciate how technical debt impacts different aspects of the business.
As noted during our discussion of code debt, decreasing development speed is the first significant area in which tech debt can impact business operations. In addition, unchecked debt often results in software developers needing to devote more time to dealing with increased bugs and system failures.
In turn, this increasingly takes time away from their ability to create new features and improvements to the codebase. In addition to these internal impacts, slower development speeds and buggier code can also lead to dissatisfied customers, damage to brand/product reputation, and lost revenue.
These ongoing issues for DevOps can also hamper the organization’s ability to innovate and adapt. Innovation and adaptation require teams to have the bandwidth to develop new features and champion new technologies. What’s more, software and systems burdened by tech debt are often less flexible and more difficult to change.
Overall, system security can also deteriorate. Older, bug-laden systems become ripe for exploitation due to vulnerabilities that increasingly expose the organization to security risks. While every area that tech debt affects can cost time and money, security breaches often result in massive costs in the form of brand damage, loss of customer trust, and financial penalties.
Finally, an area often overlooked when discussing technical debt is its effect on employee morale and turnover. Professionals in every role want to be proud of the work they do and see the positive impact of their work. When flawed systems are in constant need of rework and important projects and upgrades end up in a backlog, these environments can encourage burnout and turnover, especially when DevOps team members are in such high demand.
Altogether, these areas of impact illustrate that incurring even a moderate build-up of technical debt can quickly result in a crippling impact on the entirety of a business.
This is why it’s never too early to think about how to manage it.
Systems, solutions, and stakeholders: How to start managing technical debt
Martin Fowler, a self-described loud-mouth pundit on the topics of software development, agile development, and continuous delivery, expanded on Cunningham’s popular metaphor in 2009.
His addition, the “Technical Quadrant,” provides a way to map different causes of technical debt across four quadrants—reckless vs. prudent on one axis, and inadvertent vs. deliberate on the other.
As for how we should approach the reduction of debt itself, he notes in his blog, “…usually the best route is to do what we usually do with financial debts, pay the principal off gradually… [thinking] of this as paying interest versus paying off principal can help decide which cruft to tackle.”
And this is truly the power of the technical debt metaphor—it helps us quantify and discuss something that’s inherently hard to comprehend. Moreover, it’s doubly important for those in less-technical roles, as these individuals are often decision-makers from whom you’ll need buy-in.
Use the debt metaphor as a way to highlight the business impact of your organization’s technical debt. Provide concrete examples of how it’s caused delays and problems. Quantify the ongoing and, often, growing costs to the bottom line. And present a clear plan moving forward.
And, as a proactive way of getting started, brainstorm potential solutions you can bring to the table when it’s time to talk about debt mitigation, like faster, more efficient DevOps and best-in-class automation solutions.
Why?
Because for many businesses the simplicity and flexibility afforded by the right low-code automation solution can create some quick wins, without the need for major technical overhauls or investments.
ActiveBatch provides a centralized platform to automate workflows across diverse systems and applications. With robust auditing, compliance, and monitoring features, you can reduce instances of human error without compromising speed.To learn more about how automation can help, sign up for a free demo of ActiveBatch today.
