Why does your product need good code to work? | the technical debt
What is technical debt?
Many of us know the concept or meaning of debt in an economic sense. We have all borrowed money (or asked for it), and most of us will have used a credit card.
A debt, in simple economic terms, is a commitment to pay. If you do not return the money, the different financial institutions activate interest, which can accumulate, which can cause significant problems for the borrowed party. The accumulation of interest is carrying more and more a backpack that makes progress difficult.
Let’s take this definition into the application lifecycle. This debt implies a code that (for reasons of delivery pressure or functional decisions) has not been implemented in the best way and will require a later refactoring. It is the result of prioritizing fast delivery over optimal code. That is called technical debt.
Ever since Ward Cunningham introduced the concept of “Technical Debt” in the early 1990s, development teams have often referred to the term as the evil that we must avoid at all costs during the development of a project. However, the idea expressed by Cunningham was broader: he defends that a little debt is good and necessary. As he said, “a little debt speeds up development as long as it’s paid back by rewriting the code”.
What types of debt are there?
Martin Fowler, one of the gurus of good practices in software development, established a quadrant to represent the different types of technical debt based on context and intent. This quadrant is very useful showing that debt is not always bad, if it is in exchange for faster deliveries.
According to Fowler, we define technical debt as:
- Prudent and deliberate: Occurs when the team is aware that “interest” is accruing on the debt to focus on early delivery, but the decision is acceptable if managed later. It is a very balanced strategy as we dedicate time later to repair said debt.
- Cautious and inadvertent: The team learns what the correct solution should have been after implementation. The acquired debt is unconsciously eliminated if the change is made.
- Reckless and deliberate: When the team knows the consequences and deliberately avoids managing them, prioritizing only speed over quality. Without a doubt, the worst strategy you could have in software development.
- Reckless and inadvertent: when the team is inexperienced and blindly implements the solution. A totally undesirable scenario.
Any team that finds itself in the left quadrant, that of reckless, deliberate, or unnoticed decisions, will end up in trouble. While you will be able to deliver functionality quickly initially, the increasing complexity of the code will make it increasingly difficult for development teams to scale functionality or troubleshoot. Incidents that can be multiplied if the appropriate architecture decisions have not been made during the implementation.
How to manage the debt?
If a Product Owner lets too much debt accumulate, the entire project could fall under the weight of it. When making any changes, improvements or even solving small incidents it becomes a long, complicated and tedious task. Consequently, the metaphor of money and interest ceases to be, since the economic price of maintaining a product with a high technical debt increases dramatically over time.
The debt is only associated with technical considerations of the code or the technical solution, and by definition the Product Owner tends to be more focused on the functional aspects. That is why it is especially important to know how to listen to the technical team when they indicate that a certain functional decision involves debt or that too much of it has been accumulating.
In order to keep track of the debt that comes with a project, every time you find a point of code or functionality that translates to increasing debt, you have to add a task to the Backlog to “pay” that debt later.
When it is made visible and estimated, the technical debt becomes more difficult to ignore and is planned in subsequent development iterations to fix those deficiencies or shortcuts that have had to be introduced due to certain functional requirements that required rapid delivery.
How to fix the technical debt?
There are no specific tools to “reduce” the technical debt of a code. We must talk about the whole range of tools and methods that cover a wide spectrum of areas within the life cycle and development of an application.
We often find ourselves looking for solutions for application architecture, database types, continuous integration and deployment processes, automated tests, security, protocols, and a long list of areas where we must make the most appropriate decision. That’s where our knowledge of the tools we work with, the time we have, and the functional needs, which are always the highest priority, come into play.
We must analyze the different options that exist at all times to determine the optimal and standard solution to a problem, from SOLID principles, design patterns and clean code, to development frameworks, passing through countless libraries, services or languages most suitable for every need.
Applying the appropriate tools and patterns allows us to refactor our code to progressively eliminate this debt and reduce it to acceptable levels to maintain a healthy evolution and maintenance of our product.
What should you know about technical debt?
In software development, it is necessary to ensure a good balance between the different participants in the project (from developers to business). That implies achieving an adequate balance of the triangle of time, quality and cost.
Each part of the team presses towards their needs, but quality, beyond the fact that there are no bugs in the application, is not always the highest priority since it is often not visible from the business.
However, not maintaining the quality of the code will end up having an impact on extra costs, which will only increase if that debt is not reduced through code refactorings.
Ultimately, how the code is made will determine how easy it is for that product to be scalable, salable, maintainable, testable or transferable to other development teams. Finally, it will affect the cost and delivery time of each new functionality, directly impacting your company’s plans for the product if it does not meet the cost and time requirements, nor, of course, quality.
You will find more interesting articles on our blog.