Tech debt, also known as technical debt or code debt, suggests that a simplistic, poorly understood, or “quick and dirty” solution to a software development problem (instead of a more thorough, robust solution) comes with substantial, hidden costs that organizations must pay later. Programmer Ward Cunningham originated the definition of technical debt as we know it in a 1992 article articulating that while the enterprise may save money in the short term by coding in this fashion, in the long run, “interest” from the tech debt, as with monetary debt, will accumulate, making the initial problem increasingly costly to fix as time goes on.
Tech debt may sound like a bad thing, and in many cases it is, but when managed properly it can be a useful tool to push development forward quickly when needed. Minimum Viable Products (MVPs) are often developed with a significant tech debt load attached — and with the expectation that they will need to be completely refactored or reworked if the MVP proves to have ongoing value. Tech debt is in part a recognition that doing something fast and doing something right are rarely in alignment.
Tech debt can also be generated unintentionally — sloppy programming, cutting corners or an abruptly expedited schedule are all common problems that every enterprise faces. However, a strict definition of the term would not classify these issues as genuine tech debt, though remediating the problem requires the same type of effort.
What Is Tech Debt: Contents
Identifying tech debt can be difficult. Bad code is not the same as tech debt (though the term is frequently used to imply as much). Rather, tech debt refers to the cost of incurring and later correcting poor-quality code, not the code itself.
In its purest form, tech debt is intentional with known trade-offs. Code may be written deliberately (either as part of an MVP or as a temporary solution) with the intention that it can be fixed down the line. Finding this tech debt is easy, and some developers will actively document it during the coding process, noting that a temporary solution will require some level of rework at a future point.
Other types of tech debt may be more difficult to suss out. Accidents, laziness, incompetence or a lack of proper training may introduce tech debt. User requirements may change midstream, leading to mistakes or hastily written code to ship a product on time. Or another programmer may take over a project after months or years and may make changes to the code base that introduces new problems.
One of the primary ways to discover unintentional tech debt is by listening to users, who tend to be vocal about problems. For example, users complaining about degraded performance over time could indicate you've acquired unintentional tech debt. Analyzing crash logs and application performance data can be another way of discovering tech debt.
Tech debt isn’t inherently a bad thing, but it’s rarely altogether good. Incurring some tech debt can be a valuable tool when time is of the essence, or when the ultimate quality of the finished code isn’t critical. Tech debt can be a useful tool in a proof of concept or when an absolutely essential software feature needs to be delivered to the market quickly, for example.
Problems start to emerge, however, with a significant amount of technical debt or when it is used haphazardly. In fact, some experts say that the concept of tech debt is often used to mask shoddy or lazy programming and that the core ideas behind tech debt have become increasingly misunderstood over the years. Ward Cunningham originally suggested that tech debt could be positive if a developer initially wrote poor code due to a limited understanding of the problem they were trying to solve, but with the intention of rewriting it better later once that understanding had improved. Today, much tech debt is incurred because it is simply done sloppily. If “we’ll fix it later” is frequently used as an excuse or when any poorly written code is called tech debt, then tech debt is considered “bad.”
The only form of good tech debt, like most financial debt, is that which one intends to repay, ideally quickly or in a timely manner, which gives the organization and engineering teams some leverage. As a development team increases its level of understanding of a programming problem, poorly written code should be refactored and rewritten, paying down the tech debt by producing a more sustainable, robust software product. Minimum Viable Products almost always come with tech debt — but this tech debt is only “good” if the organization plans to revamp that MVP over time.
Tech debt has been categorized in a number of different ways:
Three types of tech debt include intentional tech debt, unintentional tech debt and environmental tech debt
Managing technical debt is a complex problem, because (as with all types of debt), tech debt gets worse the longer it exists. If an organization undertakes tech debt without a plan to “pay it off,” the problem can quickly spiral out of control.
Here are some of the best practices for addressing tech debt in the organization:
Applications of behavioral analytics include:
Tech debt can also have numerous negative financial effects on the business in the following ways:
Tech debt can negatively impact business financial performance, including loss of sales, increased support costs and lower productivity.
A DevOps environment can be helpful in avoiding tech debt due to the inherent nature of continuous development. Continuous testing, automation tools and the integration of operations into the development cycle all make it more difficult to push technical challenges to the side, even in the short term. DevOps teams constantly face decisions about how to solve a problem in a way that will maximize its benefit to the enterprise. As such, they are often forced to address tech debt challenges early, often and directly.
The catch, of course, is that not every snippet of code is high quality or receives the same level of scrutiny. Even in the most rigorous of DevOps shops, a developer may have to quickly write a bit of code to address an urgent matter, bypassing the QA process. In fact, the focus on fast development and a continuous release cycle may inadvertently encourage such quick-and-dirty solutions, as no developer wants to be the one responsible for slowing down the release pipeline. Additionally, third-party libraries and legacy code that predate the DevOps structure often contain their own tech debt issues that must be managed.
Fundamentally, DevOps does not provide immunity from tech debt, and while a well-managed DevOps framework can help mitigate reliance on tech debt, many developers will rely on the same workarounds that have gotten them through “crunch time” in non-DevOps environments.
Unlike financial debt, tech debt carries a particular price, with employees and other team members paying off the debt through their substantial labors. Unlike developing new products or new features, paying off tech debt by refactoring old code is rarely rewarding work. A developer remediating old code instead of working on value-added work impacts everyone else on the team — and the business as a whole.
A heavy load of tech debt can also lead to finger-pointing and a culture of blame within a development team, leading to division and infighting — anathema in a DevOps environment where teamwork means everything. This in turn can demoralize teams and further degrade the business as the production cycle slips, new products are rushed and additional tech debt is incurred.
Ultimately, uncontrolled tech debt can create a vicious cycle that leads to dissatisfied workers, higher turnover and a range of negative business outcomes.
Once an organization finds itself carrying a heavy level of tech debt, eventually there comes a time for that debt to be paid down rather than simply managed. Here are some strategies for getting out from under a heavy tech debt load.
“Tech debt” is a frequently misused and poorly understood term, and many developers use it to apply to any type of poorly written code. That’s a mistake that limits the utility of tech debt, because when it is managed properly, it can give a business greater flexibility, agility and execution speed. On the other hand, badly managed, overused, or misapplied tech debt principles can all become severe problems, resulting in a stagnant development cycle that becomes worse as more tech debt is accrued. By working to avoid unintentional and environmental types of tech debt — and focusing only on intentional, well-documented tech debt — you can position your development team, and your business, for success.