Technical Debt
Introduction#
The phrase “technical debt” is used often. I see many junior engineers coming into the workforce learning the term second-hand. This means that the phrase has lost much of its potency at best and at worst has been distorted into an excuse for terrible code. I think it is worth breaking down the concept of technical debt to its roots, because understanding it gives programmers an edge in their everyday work.
The Origins Of Technical Debt#
Technical debt is a metaphor that was first used by Ward Cunningham - who incidentally is a co-author of the agile manifesto and the inventor of the wiki. You can read Ward’s explanation directly on the first wiki ever created (1995).
The debt metaphor represents how a person can borrow money in order to take advantage of an opportunity. Sometimes we go into debt to buy a house or take out a loan to start a business. We take on the debt because we value the expedited entry into these opportunities. However, we know that each loan comes at a cost: we will have to pay down our debt with interest.
This principle also exists when developing software. A team can chose to build expedited solutions (i.e., writing solutions before the problem is fully understood). Consider this a technical loan. As the team learns more about the problem they are trying to solve, they will need to refactor the already-written code to reflect their new understanding. This is the interest on their loan. If the team neglects to update the code, then the software will no longer solve the problem at hand - or will do so incorrectly at best. This is effectively technical bankruptcy.
How We Misuse This Metaphor#
I too often see the technical debt metaphor being used to excuse terribly-designed code - code that is very difficult to understand and even harder to refactor. Cunningham’s concept of technical debt never implied permission to write poor code. In fact, just the opposite is true. The foundation of the technical debt metaphor is the acknowledgement that you will have to pay down your debt in the form of refactoring your code. This means that you must write code in a way that allows you to understand its current state and to change it with minimal pain.
Technical Debt Is Not Bad#
The title of this section may seem like a jarring statement. Just as with financial debt, it is not necessarily a bad thing for programmers to borrow from the future. Mortgages enable you to buy a house and begin storing equity. Loans help people start very successful businesses that earn them much more then they ever borrowed. These are examples of good debt. Problems only come when you cannot repay what you owe.
Keeping all this in mind, it’s ok to build code without a full understanding. This practice affords you the ability to get your software into users’ hands. Then begins the feedback loop where you can improve your code and begin paying down the debt. I have one warning, though: you must have a plan to pay off your technical debt. It will destroy your projects if it is not paid down.
How This Metaphor Helps Us#
The metaphor of technical debt is a tool to communicate an important trade off when practicing an Agile software lifecycle. As agilists, we pride ourselves on being able to start something before we know everything. I think that we often fail in acknowledging the interest that is incurred when solving a problem we don’t fully understand yet. We must communicate and plan for the fact that the code will need to be refactored again and again - paying down the debt that got us started.