14/02/2022 | BlogPost
Technical debt is what happens when a software product needs a strong acceleration in the development of features that are included at the expense of quality in order to get it to market sooner.
The product team, specifically the development team, knows that it will subsequently have to refactor the functionality that was delivered in a reduced timeframe.
Those who know the software development world know that when needs come from the business or the customer, to typically have to have certain functionalities in a short amount of time. This often translates into reduced time for technical analysis, design, code development, and documentation, which means that frequently, little attention is given to testing, and therefore quality.
This concept is not at all new or related to the growth of start-ups around the world, but was used by Ward Cunningham, one of the Agile Manifesto authors, to explain to the investors of a new product the need for indicating the resources for refactoring the application in the budget.
To better explain this concept, we can imagine it as the parallel of installment payments, which allow you to buy a good immediately even if you don't have all the money. This means that you are willing to pay interest.
Similarly, if I need to bring a product to market but I don't have the time to complete all of the development phases, I can reduce the phases and accept the compromise and risk of having less than perfect functionality on the market, knowing I will repay that technical debt later, as is done with interest on installment payments.
As with someone who invests by making a loan, someone who decides to speed up the market access of a product knows they will have to modify parts of the product because they are either not scalable or are more difficult to maintain and evolve.
Being the consequence of a choice, it cannot be considered a simple error or accidental event, but rather, an actual strategy. It is important, therefore, not to confuse a job done poorly or a bug with technical debt, since the latter is a risk calculated to obtain an immediate advantage.
It’s very easy to draw parallels with the Agile approach or the Minimum Viable Product, i.e. a version of a product with just enough features to be usable by the first customers, who can then provide feedback for future product development.
Even if we are talking about different approaches, the advantage is often the same, which is that making new functionalities available to users allows them to give feedback and if valid, to decide to invest further and fill the technical debt acquired at a later stage.
Not all fields of application can use this approach as a tool. Among them, and in which I work there is digital health, the discipline that includes technologies and software as medical devices for the management of human health care. In these cases, it is not always possible to use technical debt to accelerate the go-to-market of a new application because, before entering the market, it may be necessary to pass tests and validation by certifiers (MDR, ISO) following anestablished process.
The possible causes and reasons are many, but let’s analyse the most frequent ones:
Time to market – the time constraint is one of the main factors that force the product team to make drastic choices and reduce the standard phases of software development.
Incomplete or ambiguous requirements – in this case, the team proceeds with only the high-level draft of the functional requirements, which is then subject to future changes.
Lack of skills – even if in their collective imagination, a product team is complete, with all the necessary professional figures and expected skills, the reality is almost always different. It’s common for teams to not to have all of the resources they desire or need, for various reasons such as recruitment time, parallel projects, and difficulty in finding specific skills.
If the technical debt is not part of the strategy, then it is definitely a mistake. In general, we cannot regardit a mistake by definition, but if it is the result of incompetence or faulty design, then we must consider it a mistake, and it is not acceptable. In this case, it is very difficult to convince investors to spend part of the budget on software refactoring.
By virtue of experience, the management is typically more accepting of quality compromises and understands the difference between speed, go-to-market, and quality. Software engineers, on the other hand, often lack the ability to comprehend technical debt since they only understand development without compromise.
We can therefore conclude that technical debt is not an absolute evil, but neither is it the perfect solution. We can only use this approach in our product development if this possibility has been introduced into the strategy from the outset. In other words, awareness that a certain approach will have consequences in the immediate and medium terms. Continuous refactoring may, at some point, require the complete redesign of important parts of the product.
Technical debt can be an ally, if you know it you can handle it. 😊