Imagine you are driving a car and notice that your brakes are no longer working properly. Instead of having them repaired immediately, you decide to first wash your car, install a new radio and temporarily fix your brakes with old parts. In this way, through your prioritisation, the execution of other tasks and the quick & dirty solution, you accumulate technical debt.
Technical debt over time
However, sooner or later, this approach will come back to haunt you, as technical debt does not increase linearly as expected, but grows exponentially over time.
As more and more of these quick & dirty approaches are used within development, the mountain of debt grows ever larger. This ultimately leads to the fact that countless tasks must be completed to resolve the problems.
This development is fundamentally also due to the fact that the use of agile working methods and DevOps increases the pressure from stakeholders to achieve more in ever shorter timeframes.
This article goes into more detail about what technical debt actually is and what causes these debts. How it affects a product or service. And how it can be managed effectively.
What is technical debt?
Whenever unsound paths are taken, a new debt is created towards all stakeholders involved. This debt usually becomes visible when the systems or software used do not work properly or run unstably. Subsequently, significant additional effort is required to fix these errors.
This can be further simplified by viewing this debt as a gap between software that has been carefully considered, designed, developed and tested, and software that has simply been thrown together.
How can you recognise technical debt?
- Missing or no documentation: Nowadays, work is expected to be done quickly and agilely. As a result, documentation is often left behind. However, this means that usually only a few people know the current state of the project. Other or new employees are left out in the cold and plough on regardless.
- We'll deal with it later: Of course, projects need to be completed. But as the saying goes, "Do it right the first time, or you'll have to do it twice".
- Copy & Paste from other projects
- Shortcuts and cost-cutting: Quality control and testing, for example, are not carried out due to deadlines
- Bug fixes and minor adjustments take longer to implement
What causes the accumulation of technical debt?
Lack of vision or concept for the finished software
It should be clear from the outset what is to be developed. If this is missing, it very often leads to rework on the design, user interface, architecture or infrastructure. This leads to problems and poor code quality throughout the project.
Missing or inadequate documentation of requirements
Software requirements are often only vaguely or sparsely described. This means that teams and employees do not know 100% exactly what is to be achieved. This creates additional burden 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 there are excessively high expectations of the project team and that initial 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 rather than quantity.
Insufficient collaboration among employees
In software development today, agile methods such as SCRUM are usually used. This assumes that all employees involved are proficient in this methodology and can work together seamlessly from the start. This is often not the case and quickly leads to miscommunication and frustration within the team. Tickets are left pending and/or only sparsely addressed. And new issues are added every day.
Bottleneck effect - Lack of staff, time, and too many tasks as an obstacle
It remains problematic to pay down the "debt" when employees themselves become a bottleneck within the company. It is often the case that only a few employees are familiar with the systems and know how to maintain them. If these employees are then unavailable, ill, or in the worst case resign, no one is left who knows the system, leading to a complete standstill. Such a case should be identified early on and actively addressed.
Change of technology used or a new version
There are updates every day that cause changes in the code and the approach. As a result, existing code components may become redundant, no longer needed, or cause problems. This must first be fixed in a further iteration, which in turn leads to technical debt.
Lack of a quality control process
Whether in small or large teams, code quality must always be checked to determine whether all parts work perfectly together at the end. Missing quality assurance processes ultimately cause additional work and further tasks to combat the problems.
The causes that lead to the accumulation of technical debt can be varied. Those listed here are a first indication for acting directly and proactively.
How can technical debt be avoided and paid down?
Regardless of how technical debt arises, there are some recommendations for action to proactively prevent its occurrence.
Prioritisation of tasks
If shortcomings have been identified, they must first be documented and then prioritised. How these shortcomings are prioritised and addressed ultimately depends on the framework conditions created (team, working method, strategic decisions, or the tools used).
In agile teams, it is often already the case that the priority of tasks is determined in daily meetings or sprints. Recurring issues and other tickets are therefore usually ranked higher and dealt with promptly. In addition, the prioritisation of tasks also arises from the impact of the problem on the overall enterprise (e.g. impact on usability, revenue, 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 placed at the top of the backlog and included in the sprint in the next meetings.
Development of a code style guide
A simple way to prevent technical debt from arising is to set guidelines before the project starts. This is to ensure that several different approaches are not used.
Ideally, these should define exactly how the code should look. That is, for example, where commas, breaks, or brackets must be placed. This also offers the significant advantage that the structure and layout of the code are clear.
Code refactoring
In the heat of the moment, it can easily happen that code is written without paying attention to its structure or readability. This makes it difficult to keep track of things, fix bugs, or implement new features as the project progresses. To get a handle on the situation, code refactoring offers an approach to optimise and revise existing code step by step.
Tools for visualising technical debt
With the help of a few tools, omissions or structural problems in the code can be avoided from the outset or at least checked and optimised afterwards. One of these is SonarQube.
This tool analyses your code for quality and security and indicates where code segments, for example, are duplicated. It also provides a time estimate of how long it will take to reduce technical debt within the code.
SonarQube offers the option to detect future technical debt during the software build process and can be configured so that builds receive a “failed” status if the technical debt is too high.
Do not allow individual code ownership
As mentioned above, it is not a good idea for only one or a few people/developers to be responsible (and irreplaceable) for critical systems. 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 holds back them and the company's growth. In addition, code ownership causes problems for the organisation and for the code owners. If no one knows how a system works, no one can give effective code reviews. Worse still, the code may not be reviewed at all.
If the team is responsible for the code, everyone can help make design decisions. Everyone can participate in the discussion about the system design, contribute ideas, and share responsibility for these decisions. Furthermore, it is no longer such a big deal if an employee is no longer involved in the project or is sick.
Summary
One must be aware that “technical debt” initially offers no obvious or tangible added value and that it takes a certain amount of time to pay it down. In addition, most results only become measurable and visible over time. However, this does not mean lying on the couch and hoping for the best. Ultimately, one should therefore ask oneself which debts make sense to pay down, which have the greatest impact on business or economic factors, and for which a reduction would have no effect whatsoever.
