The concept of technical debt has been associated with problems with code for years. At Hexacta, we prefer to refer to it as the project’s lack of technological upgrade over time, which can impact the quality and the performance of the software. What is this all about? We will tell you here!

The management of software projects is a thrilling and challenging discipline that involves some central factors that have to be taken into account, such as time, resources, and the scope and quality of the work. Clearly, the challenge is to modify and adapt some of them to maintain all of these variables under control and in a systemic balance.

Additionally, and just as important, there are some secondary variables that deserve attention because they can directly affect the balance and stability that is sought out in the management of development projects. Within this group of variables, you can find the ones related to the human, emotional, and motivational factors of the team’s members, the technological progress, or the changes of the context in which the product is being developed or maintained, among others.

Even though there is an extensive bibliography and a variety of techniques to carry out the handling of these principal variables, the management of the secondary variables is still a less explored field.

For that reason, in this article, we want to go in-depth into one of these secondary variables: the technical debt. Firstly, we are aware of its major impact, especially on big projects, and secondly, it is a variable that is not taken into account as commonly as it should be.

Technical debt in a few words…

The regular process of a software development project, independent of the lifecycle chosen for it, usually consists of the following stages:

As it can be seen in the graphic, the design of the architecture and the definition of the set of frameworks and technologies to use is something that occurs in the earliest stages of the project. Then, the process continues with the development and the incorporation of its own features of the software that is being made or maintained. This is clear and works very well, except for the following axiom:

The technology, frameworks, and tools we use to develop software advance at a much higher speed compared to the speed that advances the software we are constructing or maintaining.

Let’s take as an example a project that consists of the development of a web app that has been in the development process for two years. It is very likely that the techniques or frameworks we decided to use when we started showing modal dialog boxes may stop working today (or in the not-too-distant future) because of some new security constraint that the browsers add to the way in which they execute the Javascript code. This is precisely what technical debt refers to.

The concept has been associated for years – thanks to Ward Cunningham, one of the authors of the Agile Manifesto – with those problems with code that many software teams have to deal with and that, at the end, become a financial debt.

However, at Hexacta, based on our experience, we conceive the technical debt from a view related to the passage of time and the technological advancement that is not merely associated with human factors.

Therefore, when talking about technical debt, we refer to the lack of technological upgrades over time, which can cause severe problems in the quality and the performance of the software.

Are you free of debt? How to avoid it successfully

The cost of accumulating technical debt is very high, and what is even worse, it is difficult to measure since it depends on a large degree of external factors. For example, we cannot control when a browser releases an update.

How can we face technical debt? Keep in mind the following 4 tips:

1. Train the client

None of the corrective actions that must be taken into account to avoid accumulating technical debt are likely to be carried out if the client does not understand the need for them as well as the cost for the project if they are not implemented.

Each time an improvement opportunity is detected, this has to be explained in a detailed way, and an estimation of the necessary work has to be specified in order to apply it. Then, it is the client who has to prioritize and manage it inside the Backlog, as any other task.

Content related: 4 reasons why splitting an unfinished Product Backlog Item is a bad idea

2. Check the critical technical aspects frequently

This is a practice that, from our experience, has given us good results. It consists of including some User Stories related to the state of the art of the tools and technologies used in every 6 Sprints in order to detect problems on time and take the necessary corrective actions.

Another key moment for the detection of improvement opportunities and to avoid increasing the technical debt is during the end of Sprint meetings that look for continuous improvement.

It is important for the Scrum Master to be aware, in the Retrospective meetings, not only of the identification of improvement opportunities but also of possible problems.

Do not miss this: The Scrum meeting and how to get a successful Sprint Retrospective

3. Ensure there is a support structure in the development company

Another important point is to take advantage of the resources a software development company with a solid structure can offer to mitigate the problems. For example, in Hexacta, we have the Hexacta Architecture Team (HAT), as well as the Quality Assurance (QA) team.

The HAT provides support and solutions to project managers in matters of architecture, design, technologies, and frameworks, guaranteeing improvement in the quality of the services and the productivity of the team. This workgroup knows about the technological stack of each project and is aware of the evolution of it to give alerts about possible updates of some components that may affect the architecture of the project. The HAT is the R&D team that is responsible for investigating new technologies and taking part in different activities of the software development community.

Furthermore, the QA team constantly ensures the correct application of the processes, so it guides the project managers not to forget the feedback that gives rise to improvement opportunities aimed at the non-accumulation of technical debt.

4. Ease the implementation of the required actions

We always have to guarantee that the implementation of improvement actions for the non-accumulation of technical debt is safe and does not bring in new problems.

It is necessary to have a high degree of coverage (of unity, systems, and load) to protect ourselves and be sure of the changes we are bringing in. Moreover, it is recommended that the changes introduced to solve some aspects of technical debt are isolated, that is to say, that they do not should be included in the same version of the application that introduces the new features, in order to identify new problems that can emerge due to those changes.

To Sum Up

The cost of accumulating technical debt is very high both for the client company and for the development company, which is why it is necessary to manage it as a risk that is always delayed in the process.

The best way to moderate it is by not forgetting about it, to always be aware of the upgrade of the technology used, to detect changes that put some part of the project at risk, and to carry out the proper actions to implement the improvements at the right moment.

Are you searching for the best technical solution for your company? Do not hesitate to Contact us for more information. We will get back to you!