1. Introduction
Technical debt arises when a team decides to use a cheaper or simpler solution that is meant to be refactored in the future to save time or cost. Sometimes, those “we will refactor it later” parts accumulate and result in great technical debt. Later, it can have significant negative impacts on the project. Further, it could be very dangerous and even decide about the project’s success or failure. In this article, we’ll elaborate on technical debt and its dangers.
2. Fundamentals
In other words, technical debt consists of project parts that are meant to be temporary solutions. Over time, those parts can be forgotten or there are so many that it isn’t possible (because of time or cost needed) to replace them. Thus, they become the project’s weak and error-prone points. Let’s elaborate more on what situations could contribute to the growth of technical debt.
First of all, the client’s decisions can impact the technical debt. For example, inaccurate, fast-evolving requirements or strict deadlines can force the team to use simpler and quicker solutions. Those solutions can be inefficient, messy, and hard to maintain.
On the other hand, the team can be one to blame. Especially as it comes to the beginner phases of the project. Lack of good practices, and refactoring during the first stages of the project can be problematic in the future. Subsequently, the project gets bigger maintaining clean code and its standards usually get harder.
Finally, focusing on quick profits, releasing an unready and unfinished product, and changing requirements too late can also increase technical debt.
Overall, there are different types and reasons for technical debt. Martin Fowler, a known developer, and author defines the Technical Debt Quadrants. It describes two types of technical debt, namely Deliberate and Inadvertent. Moreover, it considers two approaches of taking on the technical debt: Prudent and Reckless. Let’s see ho the quadrants looks like:
Now we know how and why technical debt arises. Why is it so dangerous, though? We’ll discuss that in the next section.
3. Symptoms
As we mentioned earlier, technical debt can negatively impact the project. In some situations, it can even lead to project’s failure. From the business point of view, inefficient or incorrect functioning of the software can result in bad relations with the clients.
The technical debt’s symptoms can be found in various places related to the project. The most important layers are architecture, infrastructure, implementation, development and deployment process, or team member’s skills and cooperation. Identifying technical debt symptoms and their placement can help to plan a strategy to deal with it and decrease it in the future.
First of all, as it comes to architecture and implementation, the symptoms are clearly visible, especially for developers. These include:
- unreadable and unclean code
- lack of automated testing and test environment
- inelastic code
- incoherent data model and architecture solutions
The above symptoms are easily noticeable in the developer’s approach. They could be afraid of modifying the existing code and refactoring. Moreover, they could face a large and growing number of bugs. Finally, their willingness and desire to work in the project decreases, and the progress requires more time than before.
Further, as it comes to team-related symptoms, the most important ones are the lack of knowledge or skills of some team members. Subsequently, rare meetings and communication problems are also undesirable. Moreover, sometimes members are working on several projects which can limit their availability and lead to delays.
Finally, regarding the development process, a variety of cases in different stages can occur, including:
- lack of CI/CD infrastructure
- poor code quality verification process
- insufficient requirements management and features prioritization
- underestimated projects or features
- absence of bug-fixing time monitoring
- unclear support and maintenance process
Every problem during the development process can differently and negatively impact the project and its delivery time and costs.
4. How to Measure It?
How to estimate the technical debt size? It’s a very important step to be able to effectively manage and successively reduce the technical debt. At first, the topic seems to be complex. There are a lot of variables regarding the software quality, for example, maintainability index, code coverage, arity, etc. First of all, audits can be a helpful tool to create a general overview of the technical debt impact. As an example, due diligence or code quality audits can provide useful metrics about the risks and development potential.
Although, with a big number of brode metrics it can be still hard to create a concrete plan to identify and decrease technical debt. We would wish a concrete measure of the technical debt itself. Therefore, we can use a ratio. Technical Debt Ratio is a ratio of the remediation cost (a cost to fix a software} to the development cost. A bigger ratio means the worst quality of the software. So, the equation looks as follows:
A development cost is the total number of hours required to complete the project. It can be estimated in many ways. For example, it can be expressed as:
Where LOC is the number of lines of code and CPL is the cost per line (in hours).
Furthermore, the remediation cost can be described as any code quality metric function that suits the team. For example, it can be expressed in time using cyclomatic complexity.
The good news is TDR can be calculated automatically using tools such as SonarQube. Therefore, we can constantly see how TDR changes while the project is being developed.
5. Paying the Debt
In some cases, technical debt could be demanded. It can be compared to a financial debt caused by a credit. It can allow the organization or product to grow faster and obtain leads or clients.
Although, sooner or later the debt must be paid. The bigger the debt is the more it costs (due to growing interests). Paying a large technical debt can be costly in terms of time or money. So, the product can become unprofitable and fail.
Therefore, it’s important to identify and start paying the technical debt as soon as possible. More or less, paying the technical debt means reducing the symptoms we mentioned in section 3. Let’s define a few example actions to take to pay the debt.
6. How to Pay?
First of all, we should take care of the codebase and its weaknesses. Providing good quality code is a crucial task. Therefore, there is important to add the code review as a daily routine while making pull requests. Checking our code by other team members will not only increase its quality but also improves our skills.
Moreover, code inspections and style guidelines, especially our automated ones we’ll give a constant boost to the code quality. Subsequently, we can also use pair programming from time to time.
The second important thing is testing. It can be beneficial for the software on many different levels. Starting from the code level, providing unit tests to validate the correctness is a must. I will protect the software from regression or issues while developing new features or modifying the existing ones. Then, arranging the test environment and manual testers will help to validate our features up to releasing them on production.
Finally, there are steps that can be done regarding the whole organization. Everyone should know their own and other’s responsibilities. Subsequently, clearer communication within the organization is important. Employees should know to whom and how to communicate in any case.
As it comes to the team, internal feedback is very important. It can help to solve any issues and conflicts within a team’s members. Following, changes and risks should be efficiently managed. That means all the holidays or team changes or project changes should be handled in a way that won’t impact the overall process.
Additionally, a stable vision of the company is important for each employee to feel comfortable and stable in the working environment. To sum up, paying a technical depth could be a very complex task. In this section, we’ve brought up some ideas on where and how to start.
7. Conclusion
In this article, we’ve elaborated on the technical debt. We’ve talked about its fundamentals, symptoms, and measurement. Finally, we’ve mentioned some basics ideas of how to get rid of it. We can see, that technical debt can be found in different levels of the product and it can have a significantly negative impact. Therefore, organizations should take an effort from the very beginning of the product to minimize and avoid technical debt.