Digitalisering
23. juni 2023
A different understanding and approach to ‘technical debt’
In the modern world of software development, the term “technical debt” has become well known. However, I do not believe it is the most accurate and useful way to describe the challenges. Instead, I would call it: ‘Technical obligations’.
Indhold
Mere end dårlig kode Kvantificering af gæld Opfattelse af gæld Ikke alt er dårligt Usund konnotationBelow, I have provided 5 reasons why I do not like the concept of ‘technical debt’.
1. Technical debt is more than just bad code
One of the biggest challenges of using the term “technical debt” is that it is often equated with bad code.
But technical debt is much more than that. It can include:
- Lack of documentation.
- Inefficient processes.
- Outdated technologies.
- and much more.
By limiting the definition of technical debt to only being about bad code, we overlook the many other factors that can negatively affect the software development process.
For example, a lack of documentation can be a form of technical debt that makes it difficult for developers to understand and maintain the code.
It can take a long time to recreate the context and understand previous decisions, resulting in inefficiency and potential errors.
By broadening our understanding of technical debt, we can better identify and address the various challenges that may arise during the development process.
2. The challenge of quantifying technical debt
Another challenge of using the term “technical debt” is that it is difficult to quantify.
- How much technical debt do we actually have?
- Is it something that needs to be paid back in a year or in five years?
Without a concrete way to measure and assess technical debt, it can be difficult to prioritise and allocate resources to solve the problems.
A more precise approach is to identify specific technical challenges and calculate their impact on the development process.
By quantifying the time and resources spent addressing these challenges, we can gain a better understanding of the overall technical debt and prioritise efforts accordingly.
This enables us to make well-informed decisions and minimise the negative consequences of technical debt.
3. The diversity of perceptions of technical debt
One of the biggest challenges of using the term “technical debt” is that different people have different perceptions and definitions of what it means.
Ask ten engineers what technical debt is, and you will get ten different answers. Some may mention bad code, while others may mention lack of documentation or inefficient processes.
This diversity of perceptions can create confusion and misunderstandings when we try to discuss and address technical debt as a team.
If we do not have a shared understanding and definition of what technical debt means, it can be difficult to communicate and collaborate effectively.
It is important to establish a clear definition and communicate it to the entire team to avoid misunderstandings and misperceptions.
4. Not all technical debt is bad
Another reason I do not use the term “technical debt” is that it implies that all debt is bad. But that is not always the case.
Sometimes, taking on technical debt can be a strategic decision to achieve short-term benefits or accelerate the development process.
It can be a necessary investment to meet business requirements or hit a deadline.
It is important to distinguish between “bad” technical debt that creates problems and hinders the development process, and “good” technical debt that is a deliberate strategic decision.
By taking a more nuanced approach to technical debt, we can better assess and manage the different types of debt and make informed decisions about how to handle them.
5. The unhealthy connotation of debt
Finally, the term “technical debt” carries a guilt-laden connotation that can affect our perception of and approach to the challenges.
When we talk about debt, it can make us feel guilty or ashamed about having taken shortcuts or made strategic decisions that led to technical debt. It can also create a sense of constraint and lack of options.
Instead of focusing on guilt and constraints, we should view technical debt as an opportunity for improvement and growth.
By identifying and addressing technical challenges, we can strengthen our development process and create future-proof solutions. It is not about blaming the past, but about learning from it and making informed decisions for the future.
Managing technical debt more effectively
Now that we have examined the challenges of using the term “technical debt”, it is important to look at how we can manage it more effectively.
Instead of focusing on paying back the debt as a large and overwhelming task, we can take a more strategic approach to managing technical debt.
One of the first steps is to identify and quantify the specific challenges that make up technical debt. This can include bad code, lack of documentation, inefficient processes, etc.
By identifying and prioritising these challenges, we can focus our efforts and resources on the most pressing issues.
Another important factor is to involve the entire team in the process. By creating a shared understanding and definition of technical debt, we can ensure that everyone is aligned and working towards the same goals. It is also important to recognise and reward the efforts made to address technical debt. This can motivate the team to prioritise and manage technical debt on an ongoing basis.
Finally, it is important to have a long-term strategy for managing technical debt. This can include regular technical reviews, automated testing, and continuous improvement of the development process.
By taking a proactive approach to managing technical debt, we can minimise its negative consequences and create a more efficient and sustainable development environment.
