What is Technical Debt?
Technical debt is a programming concept that strives to identify the difference between the easy programming solution and the best programming solution.
It is not uncommon for coding teams to work under conditions that value quickly generated, easily implemented code.
The downside to this approach, however, is that this easy-solution code that is produced for short-term application may not always be a good fit overall. It may require refactoring, or restructuring of the code to make it a better overall solution.
Refactoring requires additional time and labor, both of which jeopardize a team’s ability to deliver on time and under budget.
The Financial Debt Allegory
The term “technical debt” represents a development team’s options in the context of accumulating the burden of debt within the financial sector.
Borrowing money to expedite a project certainly will produce results, but borrowed money accrues interest that must be paid back at a later date. Using code that was quickly generated as a short-term solution is like borrowing money. The interest that accrues is paid back at a later time by the need to refactor the code.
The time savings that were generated by selecting the easy coding solution can be negated later when refactoring is necessary. Likewise, assuming a large debt that one does not have the means to repay can offset the benefit that the quick cash provided, and can even leave borrowers underwater.
A Balancing Act
In the worlds of business and finance it is often said that in order to make money you have to spend money.
Companies and individuals alike incur debt every day because they do so strategically, and in a way that provides an immediate effect without bankrupting them in the future. For example, few people have the cash on hand to purchase a car outright, so they incur debt in the form of an automobile loan in order to commute to work.
The dealership that sold the car may take out a loan to purchase another car lot. The loan that funded the dealership’s expansion will accrue interest, but the increase in sales that comes from the second car lot makes the debt worth it.
Those same concepts can be applied to the idea of technical debt. In a perfect world, code would be completed quickly and flawlessly without any refactoring needed. We know that this is not the case.
Decision makers (such as Product Owners and Scrum Masters) have to make the sometimes-difficult call of electing to assume debt and pay the interest later, or set realistic goals that include producing the best possible code in a longer time frame.
Often, decision makers that set realistic expectations and are aware of the needs of their teams will see the best success. After all, the best decision is an informed one.