Published Date: September 1, 2021
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.
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:
- Intentional tech debt: Intentional tech debt is created deliberately so an organization can get its product to market quickly. This form of tech debt involves a premeditated choice. Essentially, the organization is saying that it will accept some level of instability, insecurity, poor performance, user dissatisfaction or some other type of problem in exchange for launching the product sooner. This form of tech debt is risky, but it represents a known risk that all stakeholders can document, track and remedy at the appropriate time.
- Unintentional tech debt: This form of tech debt arises from sloppiness, unexpected complexity, or a lack of technical expertise in software engineering. When management unexpectedly moves a shipping deadline up a week, causing engineering teams to cut corners, incompletely test their products or introduce inadvertent bugs into the product, unintentional tech debt is often the result. This type of tech debt may be documented, but usually it is not because it often remains unknown for a while. Unintentional tech debt can still be remediated, but the development process will need to be adjusted accordingly, building time into the sprint system to revisit code that has already shipped.
- Environmental tech debt: This last category of tech debt is one that has accrued over time and without active effort. A program may be developed perfectly and launched to great acclaim, but if it is not actively managed, environmental tech debt is likely to occur because the environment will be in flux. For example, an operating system will be patched, introducing inconsistencies and incompatibilities; upgrades to a vendor’s API or a required software library may introduce compatibility issues; or security patches may prevent an application from working properly. Failure to keep up with these changes will inevitably result in an application that no longer functions properly, and like any other form of tech debt, it is a problem that gets worse over time.
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:
- Explicitly include tech debt in the scrum/sprint process: The goal is to ensure that paying off tech debt is part of the daily development process and isn’t indefinitely relegated to the backlog.
- Track tech debt meticulously: You can’t fix what you can’t see. Be sure to monitor, track and prioritize tech debt, just as you would with any other development challenge.
- Reward maintenance work, not just new product releases: It’s common for organizations to call out software developers who release a flashy new product to the market. Don’t ignore the people working hard to remediate and maintain functionality of existing software projects and products.
- Set quality standards and adhere to them: If coders are deterred from shipping sloppy code, accidental tech debt becomes easier to avoid and easier to manage.
- Avoid sudden schedule changes: Tech debt is often unavoidable if management continuously changes the rules on developers or moves deadlines. Provide realistic schedules, methodologies and realistic workloads to keep tech debt manageable.
Applications of behavioral analytics include:
- Dissatisfied users: Tech debt generally results in buggy code, which in turn results in poor user experience and lack of satisfaction. This ultimately translates to increased expenses (due to an increased need for customer service) and lower revenues (due to customer defections).
- Longer development cycles: As tech debt worsens, it becomes harder for developers to work within the existing code base, splitting time between developing new features and correcting old ones, which slows the build process and delays time to market.
- Limited innovation: When tech debt is severe, developers need to continue servicing the issues instead of devoting time to building innovative new features.
- Potential security problems: Poorly written code is often poorly secured, which can introduce unexpected vulnerabilities to enterprise software systems.
Tech debt can also have numerous negative financial effects on the business in the following ways:
- Direct loss of sales: Customers unhappy with buggy software are likely to cease being customers.
- Increased support costs: Customers who remain will require more attention, often with customer support.
- Increased developer headcount: Managing tech debt requires additional human capital to remediate debt-laden software.
- Lower productivity: Developers are unable to devote as much time to developing value-added software features, lowering overall productivity and impeding business goals and business needs.
- Increased risk of a security breach: Security breaches are laden with financial risk, including direct loss of assets, loss of business, and the risk of regulatory fines and penalties.
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.
- Separate good tech debt from bad tech debt: It’s important to categorize tech debt based on where it originated and whether it was intentional (good) or otherwise (bad.) Whatever strategy you use to get out of tech debt, you will generally need to focus on the bad tech debt first, which can have the most significant impact on the business.
- Get software developers on board with a remediation strategy: When tech debt becomes overwhelming, it’s time to call all hands on deck and come to terms with the problem. Many developers are likely to resist a change in priorities that tasks them with focusing on refactoring old code instead of developing new features and products, so it’s important to position this work as a team effort. Rather than dumping the job on a handful of developers, consider splitting up the job among the entire team.
- Prioritize the biggest problems: If tech debt is causing an application to fail or is exposing a security flaw, you need to address these issues first. Questionable code that has less of an impact on performance, for example, may not need immediate attention.
- Develop metrics to measure the impact of tech debt: These metrics can be customer satisfaction ratings, application crash data, or even performance- or financial-related, depending on the type of code. Monitoring these metrics over time will let you determine the success of your remediation efforts, which can be used to inspire the development team.
- Make tech debt remediation an ongoing job: Just as DevOps stresses continuous development and integration, tech debt remediation should also be part of the continuous release cycle. Build remediation habits into daily scrums and sprints, and eventually, it will become a natural and expected part of the production cycle.
“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.
