Technical debt is a euphemism referring to the risk in production and potential rework assumed in software development. Due to rush and other factors, a lack of quality in deployed software developments is allowed.
It is normal that resources or quality are limited in every product, but in the business world and in any professional field, the debt must be known or predictable so that it can be managed, so as to avoid going bankrupt. Technical debt starts to sound a lot in developers communities, but apparently no so much within most business circles. For IT Managers, the concept is as unknown as the name of its creator, Mr. Ward Cunningham.
“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”
Ward Cunningham, 1992
Cunningham says a software whose code is full of harmful constructions for deployment, security and easy maintenance is an investment tactic focused on short-term profit. In finance, we know that this “speculation” can generate debts whose interests have to settle for very long or indeterminate periods of time. Piling up on this debt can also lead to technical bankruptcy.
We insist. The debt is present throughout every development, consciously introduced because there is no time to make things right, but an IT or Development Manager can only manage it if they can identify it within their portfolio, measure it, know its concentration and understand the problems it is associated with.
Let’s take some everyday examples, like owing money to a friend or relative, paying fines or paying the mortgage. In the case of a loan between acquaintances, the risk is low and, although this examples is not morally right, in this case, beyond the possible breakup of a relationship, nothing will happen to us if we do not return the money. A similar case can be a problem of poor documentation in the code or high complexity in applications which are not residually modified more than a few times a year.
Then, there is the case of fines. If we do not pay them on time, they charge and, if it takes too long, our bank account can be seized. But even at that point, if we pay, we can fix the situation. There are security, maintenante or reliability problems that we can assume for a period of time, because they will not stop the business, but they will make us lose money that we could have used to innovate.
The case of the mortgage does not need much explanation. We do not pay, we are homeless and we lose all the investment made so far. We need to know what dangers lie in the code, which quickly become into falls, vulnerabilities or bottlenecks, fatal for critical applications that support the business. In other cases, consumption of machine and MIPS will soar or a maintenance will be so expensive that the use of a given application will be unsustainable.
Quality and security deficiencies originate risks that should be prevented and repaired. The unknown risk is tipping the balance of the budget to corrective and preventive maintenances, which do not generate value to the business and place the IT areas in a reactive position. Not managing the technical debt and the associated risk spends the budgets for new projects and ends up being a tremendous drag on innovation.
Thus, some IT excecutives, especially developments directions, relation with software factories, production and even CIOs, already use information pointing them the applications that need immediate remediation, in which they must maintain focused and in which they should stop investing.
For instance, there are the application rankings, from higher to lower investment risk, grouped by cricicality for business, size, etc.
Then there are the relative decision quadrants, where the applications are sorted by technical debt related to production, security or maintenance problems. They set what applications have the highest risk, complexity and their size, as well as filtering by layer, functional area, etc.
Finally, what allows the decisions based on this analytic of the technical debt in an applications porfolio to catalyze is the generation of action plans based on business priorities. Fix the maintenance and security problems first and solve what each business requires in the short and medium term.
Understanding and managing the technical debt hidden in the code involves eliminating the risk it generates. Therefore, investing in software analytics services and solutions is a sure way to start protecting your software investments.
