According to recent surveys, organizations waste between 23% and 42% of their development efforts on technical debt [1]. This logically impacts their budget and bottom line as well. A separate survey revealed that more than 20% of the average organization’s IT budget is related to resolving technical debt [2]. It is no mystery, therefore, that companies need to understand and assess its impact before determining how to resolve it.
What is Technical Debt?
Technical debt, also known as code debt or tech debt, refers to any cost incurred as a result of faulty development or less-than-optimal maintenance of technological systems, infrastructure, hardware, and software. These components evolve and advance at an exponential rate, so the pressure to develop rapidly, even taking shortcuts, can result in increased costs in the long run. Additionally, as time goes by, updating and modernizing legacy technology becomes more and more costly. Moreover, it includes the cost of security breaches and reduced competitiveness resulting from delaying updates and improvements to the system.
Tech debt can result from a range of situations, such as an app having bugs, legacy code that suffers from low-quality design, missing documentation, and more. In most simple terms, technical debt occurs when a development team prioritizes speed of delivery over code quality.
Simplified Definition of Tech Debt
While technical debt can begin to accrue during the initial development stage due to bad planning, poor coding, or other development shortcuts, for this article, we will focus on this more simple definition of tech debt: the cost of maintaining or improving an outdated system versus investing in emerging technologies and timely upgrades.
Why Is Technical Debt Important?
Ignoring technical debt leads to potentially disastrous consequences, including business failure. Even if not significant enough to cause business failure, not reducing it can result in extreme maintenance costs and increased downtime.
Additionally, the accrual of technical debt may indicate other danger signs, such as inefficient IT management and failure to leverage emerging technologies. Regardless, it puts a strain on an organization’s financial and human resources.
For instance, a manufacturer may have talented, experienced employees who are very skilled in using a handwritten log system to keep track of maintenance issues. They’ve been doing this effectively for years and have grown comfortable with the process. However, they could use a digital log entry system that not only provides a place to note the condition of each unit but also tracks repairs and assigns people to handle specific tasks. Not using a system like this results in significant opportunity costs. By addressing this technical debt, the manufacturer can have its talented staff invest their skills in other important tasks.
Types of Technical Debt
Technical debt can take on a few different forms, and there are two prevailing schools of thought regarding how to classify it:
Intentional vs Unintentional Technical Debt
Steve McConnell, an author of software engineering textbooks, classified tech debt into intentional and unintentional [3]
- Intentional, which is when you undertake technical debt to speed up development to meet a pressing business need
- Unintentional, which results from a development team not doing a good job, often due to cutting corners
The Technical Debt Quadrant
Martin Fowler, a software developer and author, suggests you can categorize technical debt into 4 categories using the “Technical Debt Quadrant [4], depending on context and intent. It can be either deliberate or inadvertent, and whether it’s by design or accident, tech debt can be prudent or reckless.
For example, suppose a software development team has to meet a deadline, so they develop a database app that lacks the ability to integrate existing data from Microsoft Excel. They reason, “We have to meet this deadline because key stakeholders need the app up and running in three weeks‚—with or without the Excel integration.” This would be a “deliberate” and “prudent” decision to assume technical debt.
Deliberate Technical Debt
Put simply, deliberate technical debt involves choosing to allow “debt” to accrue. However, the choice can be either reckless or prudent.
- Reckless and Deliberate: Choices to take shortcuts in the planning stages may reveal a recklessness that can create a snowball effect of tech debt accrual. Usually, this describes choosing speed at the expense of quality.
- Prudent and Deliberate: In software production or updating, sometimes the need for speed of delivery outweighs the cost of working out bugs or vulnerabilities at a later stage. Or an IT team might delay replacing components until an anticipated newer technology emerges. These choices are deliberate but likely wise.
Inadvertent Technical Debt
Conversely, technical debt can be accrued inadvertently because of oversight, negligence, or ignorance. Inadvertent debt can either lead to prudence or reveal recklessness.
- Reckless and Inadvertent: Insufficient testing or recklessly disregarding standards can result in costly downtime or system failure. Solutions may be implemented hastily and blindly, further compounding the debt.
- Prudent and Inadvertent: At the time of development, a team may be unaware of methods, solutions, or technologies. Additionally, the requests of a client or management may increase the complexity or intricacy of system components and software, creating technical debt from outside the development or IT management team. However, if the lessons are learned and the team evolves and grows to meet the challenges, such inadvertent debt results in prudence.
The 13 Types of Technical Debt
More recently, a paper published by the Software Engineering Institute categorized 13 types of technical debt and the key indicators for each type. The paper was entitled “Towards an Ontology of Terms on Technical Debt [5] ,” and the following are the distinct types of debt:
- Architecture Debt — debt created by an architectural approach that was only effective in the short term, requiring extensive reworking later.
- Build Debt — debt created by technical issues that make each build more complex and resource-consuming than the last.
- Code Debt — debt created by issues with the source code.
- Defect Debt — debt created by defects found during testing that were deferred due to limited resources or alternate priorities.
- Design Debt — debt created by a failure to follow best practices and principles of design.
- Documentation Debt — debt created by inadequate documentation leading to a waste of resources in the future.
- Infrastructure Debt — debt created by infrastructure deficiencies that create obstacles to development.
- People Debt — debt created by unresolved issues with staff training or distribution.
- Process Debt — debt created by inefficient or outdated processes.
- Requirement Debt — debt created by a failure to implement requirements or partial implementation.
- Service Debt — debt created by a need for web service substitution.
- Test Automation Debt — debt created by using resources to automate previously developed tests to aid faster development and integration.
- Test Debt — debt created by issues that affect the quality and effectiveness of testing.
Is Technical Debt Always Bad?
Since technical debt can be a choice, logic follows that it is not always bad. Technical debt cannot be avoided, and some may even be necessary, but it must be managed, and reducing bad technical debt, inadvertent debt, should be a priority. Gartner predicts that organizations that manage and reduce technical debt will “achieve at least 50% faster service delivery times to the business [6].” So, what is an acceptable amount of technical debt, and how can it be managed responsibly?
Each organization will ultimately need to decide how much technical debt they will allow to accumulate before it adversely affects their bottom line. The 80-20 rule, however, is widely accepted. This means that 80% of time and resources are spent on new features and technologies, while 20% of time and resources are allocated to reducing or managing technical debt.
Common Causes of Technical Debt
While a management choice causes deliberate tech debt, the causes of inadvertent tech debt are varied and may overlap to some degree.
Time Constraints
Time constraints can cause debt in at least two ways. First, teams may find it easier to stick with what they know rather than take the time to investigate new methods, technologies, tools, etc. With no time allocated for exploration, known methods and technologies soon become outdated and result in the accrual of technical debt. Additionally, when there’s pressure to deliver products or updates on time, shortcuts are taken, and when there’s pressure to avoid downtime, developers and IT management teams may hesitate to perform tasks that require extensive downtime.
Changing Requirements Constantly
When a client or management constantly changes the requirements, complexity may result. The more complex the system or software, the more danger of incurring technical debt due to complicated update processes or component intricacy. Additionally, changing requirements can lead to inefficient workflow and wasted time and resources.
Outdated Technologies
Some organizations continue to use outdated technologies because of familiarity or sentimentality. However, the longer such technologies are used, the greater the cost is to modernize or replace them. The time and resources spent in modernizing legacy systems and software can cripple an organization if not handled prudently and efficiently.
How to Measure Technical Debt
It can be difficult to quantify tech debt, especially because some factors leading to technical debt can be difficult to foresee or anticipate. There are a number of metrics that can be factored in to measure your organization’s tech debt:
The Impact of Tech Debt
Just as financial debt accrues interest and increases the debt, technical debt also comes with increased costs. These costs are more than just financial, depleting an organization’s resources.
Reduced Development Speed
While technical debt can often result from the shortcuts taken because of time pressures, the irony is that tech debt reduces development speed rather than speeding it up. This is because it takes a heavy toll on productivity, and time and resources are wasted on fixing bugs and other vulnerabilities.
Increased Maintenance Costs
Increased maintenance costs can result from unnecessary downtime, security breaches due to vulnerabilities, and time and resources spent on reducing technical debt caused by inefficiency or oversights.
Diminished Code Quality
Rushed code is often considered “bad” code because the quality suffers. Prodigious amounts of time and resources may be wasted on fixing issues resulting from insufficient testing and debugging.
Technical Debt Example
STRATTEC, a company with a heritage of over 100 years, was experiencing limitations in integrating newer software with its existing ERP software. The software itself had limitations that required some processes to be handled manually. Since they target a global consumer base, these inefficiencies were affecting logistics and their bottom line, an example of tech debt accrual. However, they did not want to replace their existing ERP software.
The solution was modernizing their existing technology, leveraging RAMP from LANSA. Nick D’Alessandro, Technical Lead at STRATTEC, said that the solution ‘preserved the existing business logic while improving business processes,’ thereby reducing tech debt. You can read or download the entire case study here: LANSA Holds the Key for STRATTEC.
For many organizations, their applications and infrastructure were built on what is now known as IBM i. It started as the AS400 in the late 80’s and became known as the iSeries in 2000. Today, more than 15,000 applications run on IBM i [7]. The challenge is to reduce the tech debt of a system with that age through IBM i modernization. Platforms such as those offered by LANSA use low-code solutions to make IBM modernization easy and reduce technical debt.
Watch our webinar on IBM i (AS/400) Application Modernization
How to Manage and Reduce Tech Debt Effectively
There are a few best practices for managing and reducing technical debt. Successful management and reduction of debt depend on finding the right balance between speed and quality. For example, certain shortcuts might ensure timely delivery, but what will be their cost in the long run? Conversely, even the highest quality product will lead to losses if it is late for delivery. So besides following the 80-20 rule, the following strategies should be included to ensure a proper balance between speed and quality.
Prioritize Debt Reduction
If debt reduction is not prioritized, it can soon get out of hand, and recovery becomes less and less likely. It is important to leverage available tools to quantify tech debt and create a strategy for managing and reducing it.
Refactoring
Refactoring focuses on improving the structure and readability of code without altering its UI and functionality. Low-code solutions are becoming increasingly popular for this strategy.
Documentation
While proper documentation is one of the first things to suffer when time constraints and other pressures begin to affect development and maintenance, good documentation can save time and resources in the long run. Even when tech debt does accrue, it can be reduced quicker and more efficiently.
Continuous Testing
Continuous testing, like proper documentation, can save time and resources in the long run. Issues can be identified more quickly and addressed more efficiently.
Key Takeaways
Tech debt is unavoidable but not always bad. With proper tracking and management, it can be kept within reasonable levels. The 80-20 rule is a tried-and-true way to progressively reduce technical debt.
LANSA offers solutions to modernize IBM i legacy systems and reduce tech debt. Contact us through one of our regional offices or submit an online form.
Frequently Asked Questions
How much technical debt is acceptable?
Each organization will ultimately need to decide how much tech debt they will allow to accumulate before it adversely affects their bottom line. The 80-20 rule, however, is widely accepted. Companies would want to make sure that they can pay off their technical debt without spending more than 20% of their time and resources.
How much time to allocate to tech debt?
According to the 80-20 rule followed by many organizations, only 20% of time and resources should be allocated to reducing or managing technical debt.
What is the 80-20 rule for tech debt?
This means that 80% of time and resources are spent on new features and technologies, while 20% of time and resources are allocated to reducing or managing tech debt.
Is tech debt avoidable?
Technical debt cannot be avoided, and some may even be necessary, but it must be managed, and reducing bad tech debt, inadvertent debt, should be a priority.
Resources
[1] A. Tornhill, “Business costs of technical debt,” CodeScene, https://codescene.com/hubfs/calculate-business-costs-of-technical-debt.pdf
[2] S. Blumberg, R. Das, R. Patenge, J. Lansing, N. Motsch, B. Munstermann, “Demystifying digital dark matter: A new standard to tame technical debt,” McKinsey Digital, Jun 2023, https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/demystifying-digital-dark-matter-a-new-standard-to-tame-technical-debt
[3] “Managing Technical Debt,” Construx, https://www.construx.com/resources/whitepaper-managing-technical-debt/
[4] M. Fowler, “Technical Debt Quadrant,” Martin Fowler, https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
[5] N. Rios, L. Ribeiro, V. Caires, T. Mendes, “Towards an Ontology of Terms on Technical Debt,” Research Gate, Dec. 2014, https://www.researchgate.net/publication/286010286_Towards_an_Ontology_of_Terms_on_Technical_Debt
[6] “Assessing Technical Debt to Prioritize Modernization Investments,” Gartner. https://www.gartner.com/en/publications/how-to-assess-infrastructure-technical-debt-to-prioritize-legacy-modernization-investments (accessed Dec. 19, 2023).
[7] “IBM i History and Timeline – System/38 to AS/400 to IBM i,” www.fortra.com. https://www.fortra.com/blog/ibm-i-history-and-timeline
0 Comments