Technical Debt

The metaphor "Technical Debt"

As a result of decisions taken in the development process in favor of a fast or inexpensive solution instead of an effective one, deficiencies remain in the code and architecture. For these deficiencies, the metaphor Technical Debt has become common in software development. These technical debts cause additional expenditures for rework to avoid immediate, hidden or also future problems in the advancement of the software. Technical debt is to some extent unavoidable due to the realities of software development (tight budgets, understaffed teams or unrealistic launch dates). However, if these debts are not promptly reduced as part of the maintenance cycles, they can progressively burden the software's further development. Instead of the hoped-for acceleration of development, the further development of the software in its life cycle becomes increasingly slower and more costly, to the point of no longer making financial or technological sense. The metaphor "technical debt" correctly points to this interest and compound interest effect.

Why does software always imply Technical Debt?

In software development, the time to market is an important competitive factor for achieving a leading market position. Companies always strive to cut the duration of their product development in order to launch the software as early as possible. As a consequence of this time pressure in development, the software often contains increased technical debt. Technical debt is the result of prioritizing for a faster start of commercialization rather than a focus on code quality and maturity. Technical debt is the cumulative sum of all design decisions made during development (incl. maintenance), which are always a compromise between speed and accuracy due to demanding requirements, a tight budget and time pressure.

They are the consequence, if a today's time saving is weighted more important than the future expenditure for the subsequent required quality improvement or development of the software. For this short-term adherence to development milestones the company pays the price of ever higher development expenditures due to the growing technical debts. Accepting Technical Debt obviously does not accelerate the development time in the medium term, but actually slows it even down. As a result, this leads to longer development cycles, and in the worst case, even to the end of an economically and technically sensible product development.

What different kinds of Technical Debt are there?

The Software Engineering Institute at Carnegie Mellon University has defined 13 different types of technical debt. Below are the 13 types with examples.

Due to technological reasons:

• Architecture Debt - Due to a monolithic architecture, failure to modularize, or problems moving to microservices.
• Build Debt - By not using Continuous Integration or Continuous Delivery. Code Debt - By violating common principles such as DRY or KISS.
• Defect Debt - By not providing bug fixes.
• Design Debt - By violating design principles, which has a negative impact on the user experience.
• Documentation Debt - The lack of coding and documentation guidelines makes it more difficult for developers to understand the results.
• Test Debt - Due to insufficient test coverage or code overlap
• Test Automation Debt - Due to the lack of automatable unit tests.

The following types can additionally be classified as organizational debt as a result of organizational reasons:

• Infrastructure Debt - By impediments such as lack of software licenses or non-functioning hardware.
• Service Debt - By determining the software structure based on the producer's organizational structure (Conway's Law)
• Requirement Debt - Due to faulty backlog refinement or an undefined system context
• People Debt - With employees who are unwilling to learn and stand outside the team and do not stick to commitments such as a Definition of Done.
• Process Debt - Due to inappropriate, missing or not applied workflows and methods.

Challenges in removing Technical Debt

First, the technical debt should be identified and localized. This requires specialized knowledge and tools. Often, both architecture debts and design debts are identified. This simultaneous occurrence of different types of debts makes the solution concept and the reduction of technical debts complex and costly. Budgeting the expenses for the corresponding refactoring is not easy and they are also usually estimated too tightly.

The insufficient budget for refactoring is exacerbated by the fact that many R&D managers, when asked whether they should use capacities for the reduction of technical debt or for a new feature, usually decide in favor of the new feature. Winning new customers is often valued more highly than maintaining existing customers, who expect continuous improvement and further development of the software. Working on a new feature is also usually more exciting for developers than improving existing code. If 10-15% of the development capacity is not planned from the beginning for the reduction of technical debts, the company plays with the life expectancy of its software and the satisfaction of its existing customers.

The big challenge of the development area lies therefore in the prioritization of the technical debts, so that first those with the largest problem potential and the relatively largest improvement potential are eliminated within the reserved development budget. In this way, it is possible to keep the technical debt within the non-critical, i.e. plannable, range. For the customer, this ensures that his software does not hamper his further development over time, but that the further development of his business processes is supported by regular and punctually delivered new features.

What impact does Technical Debt have on the company?

Problematic technical debt can negatively impact companies in many ways:

1. The ability to innovate is impacted. The developer capacities required for this are either occupied with refactoring the problematic code passages or the code itself requires more and more effort to integrate new features, for example.
   
   
2. For the same reasons, the ability to react promptly to market changes is affected. This is a serious disadvantage in a competitive and customer environment that is becoming increasingly digitized.
   
   
3. Developer satisfaction and loyalty is affected. Constantly fixing legacy code frustrates a developer. They prefer to deal with the development of new innovative features. Motivation problems, quality problems and fluctuation in the team are the (expensive) consequence.
   
   
4. Customers notice the decreasing performance, the late updates and the missing or delayed innovations. They become dissatisfied and look for supplier alternatives that don't have these problems.
   
   
5. The costs and effort for maintenance and further development of the software are constantly increasing and can hardly be budgeted accurately anymore.

Is the decision to build up Technical Debt fundamentally a bad one?

Technical debt is a logical consequence of an agile software development. It is not positive or negative per se. The causes that have led to this debt are decisive in determining whether it is a useful or a problematic " borrowing" of debt. A good reason would be, for example, to bring the software to the market faster than a competitor. However, if these initially useful debts are not paid off in a timely manner, they will sooner or later become troublesome debts.

Has Technical Debt increased during the pandemic?