Imagine you are driving a car and you notice that your brakes don't work properly anymore. But instead of repairing them directly, you first decide to wash your car, install a new radio and temporarily repair your brakes with old parts. This way, with your prioritization, the execution of other tasks and the quick & dirty solution, you build up a Technical Debt (Technical Dept).
Technical debt over time
Sooner or later, however, this approach takes its revenge, since the technical debt does not increase linearly as expected, but exponentially over time.
By using more and more of these quick & dirty approaches within development, the mountain of debt gets bigger and bigger. This ultimately leads to countless tasks having to be processed in order to solve the problems.
This development is basically also due to the fact that the use of agile working methods and DevOps is increasing the pressure from stakeholders to achieve more in ever shorter periods of time.
This article will go into more detail about what exactly technical debt is and what causes it. How it affects a product or service. And how to manage it effectively.
What are technical debts?
Whenever unclean paths are taken, a new debt is incurred towards all stakeholders involved. This debt usually becomes visible when systems or software used do not function properly or run unstably. Subsequently, considerable additional effort is required to correct these errors.
This can be further simplified by viewing this debt as the gap between well thought out, designed, developed and tested software and software that is just cobbled together.
How can you recognize technical debt?
- Lack of or no documentation: Nowadays, work is supposed to be fast and agile. Documentation is often left behind. However, this leads to the fact that usually only a few know what status the project already has. Other or new employees are left out and work stubbornly on it.
- We'll deal with it laterSure, projects have to be completed. But as the saying goes, "Get it right, or you'll do it twice".
- copy and paste from other projects
- Shortcuts and savings: Quality control and testing are not performed, for example, due to deadlines
- Bugfix and minor adjustments take longer to implement
What are the causes of the buildup of technical debt?
Lack of vision or concept of the finished software
It should be clear from the beginning what is to be developed. If this is missing, there is very often rework on the design, user interface, architecture or infrastructure. This leads to problems and quality in the code during the entire project.
Missing or inadequate documentation of requirements
Often software requirements are only vaguely or poorly described. This leads to teams and employees not knowing 100 % what exactly is to be achieved. This creates additional workload and thus new technical debt.
Lack of communication and high expectations from management
At the start of a project, with new teams or when working with external service providers, it can happen that expectations of the project team are too high and the first results are to be achieved as quickly as possible. Therefore, it is important to communicate the maximum workload as early as possible and to focus on quality instead of quantity.
Insufficient cooperation between employees
Nowadays, software development usually works with agile methods such as SCRUM. This leads to the assumption that all employees involved have mastered this methodology and can work together right away. This is often not the case and quickly leads to miscommunication and frustration in the team. Tickets get stuck and / or are only sparsely processed. And new issues are added daily.
Bottleneck effect - lack of employees, time and too many tasks as obstacles
It still becomes problematic to reduce the "debt" when employees themselves become the bottleneck in the company. It can often be the case that only a few employees are familiar with systems and know how to maintain them. If these employees are then prevented from working, are ill or, in the worst case, terminate their employment, no one is familiar with the system and a complete standstill occurs. Such a case should be recognized at an early stage and actively tackled.
Change of the technology used or a new version
Every day there are updates that cause changes in the code and approach. As a result, existing code blocks may become obsolete, no longer needed, or cause problems. This has to be fixed in another iteration and again leads to technical debt.
Lack of quality control process
For both small and large teams, quality in code always needs to be checked to see if all the pieces work perfectly together in the end. Lack of quality assurance processes ultimately causes extra work and more tasks to fight problems.
The causes that lead to technical debt being built up can be many and varied. The ones listed here are a first clue to take direct and proactive action.
How can technical debt be dealt with and reduced?
Regardless of how technical debt comes about, there are some recommended actions to proactively avoid its occurrence.
prioritization of tasks
If failures have been identified, they must first be documented and then prioritized. How these omissions are prioritized and addressed ultimately depends on the framework created (team, working method, strategic decisions or the tools used).
In agile teams, it is usually already the case that the priority of tasks is determined in daily meetings or sprints. Recurring issues and other tickets are therefore usually given a higher priority and processed in a timely manner. In addition, the prioritization of tasks is also determined by the impact of the problem on the company as a whole (e.g. impact on usability, sales or experience) or how important a solution is for the performance of the product or software. The remaining tickets (e.g. irrelevant for the current Sprint) should be stored in the Backlog at the highest position and included in the Sprint in the next meetings.
Development of a code style guide
A simple way to avoid technical debt is to establish guidelines before the project starts. This should ensure that several different approaches are not used.
Ideally, these should define exactly how code should look. This means, for example, where commas, breaks or brackets must be placed. This offers the additional advantage that the structure and layout of the code are clear.
In the heat of the moment, it can happen that code is written without paying attention to its structure or readability. This makes it difficult to keep track of the progress of the project, fix bugs or implement new features. To get a grip on the situation, code refactoring offers an approach to optimize and revise the existing code step by step.
Tools for the visualization of technical debt
With the help of some tools, omissions or structural problems in the code can be avoided right from the start or at least checked and optimized afterwards. One of them is SonarQube.
This tool analyzes your code for quality, security, and indicates where code segments are duplicated, for example. Furthermore, it gives a time estimate of how long it takes to reduce technical debt within the code.
SonarQube provides the ability to detect future technical debt during the software build process and can be configured to give builds a "failed" status if the technical debt is too large.
Do not allow individual code ownership
As mentioned above, it is not a good idea to have only one or a few person(s)/developer(s) responsible (and irreplaceable) for important system. If there is a problem with the web application, the code owner is the person who has to fix it. Code ownership is bad for code owners because it stunts their and the company's growth. Also, code ownership causes problems for the organization and for the code owners. If no one knows how a system works, no one can give effective code reviews. Worse, the code may not be reviewed at all.
When the team is responsible for the code, everyone can help make design decisions. Everyone can participate in the system design discussion, contribute ideas, and share responsibility for those decisions. Further, it's no longer such a big deal if an employee is no longer involved in the project or is sick.
One must be aware that "technical debt" initially offers no obvious and tangible added value and it takes time to reduce it. Furthermore, most results will only become measurable and visible over time. However, this does not mean lying on one's lazy skin and hoping for the best. In the end, you should ask yourself for which debts it makes sense to reduce, which ones have the biggest impact on business or economic factors and which ones would have no impact at all.