You may have heard software developers and project managers talk about “technical debt”. This term has been around since the 1990s and is growing in popularity. But what is technical debt and why do people keep talking about it?
What is Technical Debt?
In software development, it’s fairly common to write a quick solution based on partial information, knowing that this component will need to be refactored later. “Technical debt” describes this need for future rework resulting from an expedient software development solution.
Here’s a stab at defining the term:
technical debt n. a condition in a software development project such that one or more of its features will need future refactoring due to decisions made early in the development process. Such decisions may have been made in order to accelerate development or testing of other features or to create an iterative solution when requirements are only partially defined. Origin: Ward Cunningham, 1992; additional clarification, 2009.
A useful metaphor
Programmer Ward Cunningham, who has made so many significant contributions to the computing world, was the first person to use the debt metaphor in relation to software development. In a report at the 1992 OOPSLA Conference, Cunningham wrote about the pitfalls of immature code. Sure, it may work, but it won’t be sustainable in the long term unless the programmers go back and consolidate. He used the analogy of financial debt to describe what can happen: “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.”
Is technical debt bad?
Many people shy away from debt automatically. To them, any debt at all feels like too much risk. Technical debt can provoke the same reaction.
Ask a programmer for a layperson’s example of technical debt, and you’ll probably hear about the “Y2K crisis”. It’s a classic example of technical debt. In the mid-twentieth century, computing was in its infancy and digital storage was very expensive. As a result of this budget constraint, programmers opted to store only two-digit years: they stored “1959” as “59”. That was a great solution at the time, but the solution stayed in place even after the problem went away. For years after the price of storage plummeted, two-digit years remained the standard. Programmer Bob Bemer warned about the problem as early as 1971, but it would take decades and over $100 billion just in the USA to fix the problem in time. The longer you wait to repay technical debt, the more it costs.
But why not write the fully robust solution the first time?
In other types of work, especially construction, there are adages like “Measure twice, cut once.” People want to get it right the first time. That’s not always possible or even advisable in software development. Requirements may not be complete before certain features are needed. Development and testing of a program may uncover new use cases or new data conditions. Programming best practices almost always include iterative development: create basic functionality with a few key features, then test and refine until the full scope is complete.
Just as there may be good reasons to incur financial debt — how many people pay cash for a house? — there can be good reasons to incur technical debt. It’s a very fitting analogy. Like financial debt, conscious management is the key. The two-digit year implementation solved a real problem when it was first developed. Like every solution, though, it needed periodic evaluation and refinement. Technical debt only becomes a problem when it’s allowed to accrue too much interest. Managed well, it becomes a tool for developing better software faster.
TL;DR
Technical debt is known future rework that results from early software development solution decisions. Like financial debt, it can be a useful tool if it’s repaid promptly or a heavy burden if it’s allowed to grow.
If you’d like more information about custom software development, click here.