The term technical debt is well known, yet few organizations have strategies in place to manage it. Unmanaged technical debt, similar to financial debt, can have devastating consequences.
The term technical debt has become ubiquitous in the tech world, it is mentioned in marketing materials, process documentation, and countless books and blog posts. Yet the concept remains a mystery in practice. A few organizations have a technical debt management process in place, and even fewer recognize the value of strategic use of technical debt, in the form of a “technical loan”.
The term “technical debt” was first coined by Ward Cunningham. Analogous to financial debt, technical debt describes how decisions we make lead to problems that get increasingly more difficult to fix over time, continually reducing our available options in the future— even when taken on judiciously, we still incur interest.
There is some debate over what constitutes as technical debt, purists argue that it should include only inefficiencies introduced through proper development methodologies, whereas others include all bad decisions that were made along the way, prudent or reckless. Martin Fowler reminds us that such a debate focuses on the wrong thing, this is a metaphor meant to help us understand certain issues. The term definition should be helpful, whatever that means for your organization.
Regardless of your exact classification, the metaphor provides a window into your organization’s hidden technology costs. When looking at such costs, however, we must also be able to identify opportunities, as just like in financial terms, there is good debt, and there is bad debt:
Though the term “debt” evokes negative emotions, not all debt is bad. In simple terms, good debt can help you grow your business. Using loans to finance infrastructure investments, inventory, or acquisitions is common. But what shape does a technical loan take? And how does one go about taking on such a loan?
During the early days of Facebook, Mark Zuckerberg used PHP as a platform for rapid product development. The platform allowed him to test out ideas overnight, scalable architecture and best practices were not a priority. Zuckerberg was taking out technical loans to rapidly add features to his platform, while his community was growing exponentially. After years of paying off interest on that technical debt, in 2008 Facebook engineers realized that the interest exceeded the value received, so they embarked on a debt repayment journey. Within two years they had created the HipHop PHP compiler, which allowed them to convert PHP code to C++, enabling them to serve six times the traffic using the same capacity. By 2012 they had practically paid off that debt by introducing the HipHop virtual machine project (“HHVM”), taking a just-in-time compilation approach.
Whether working on rapidly launching a new product to the market, or under pressure to meet market demands, I often see technical borrowing in the form of:
The list is not exhaustive, what constitutes as good technical debt is subjective, but the point is the classification of prudent “corner-cutting” as good debt.
With the debt metaphor established, I am sure I don’t have to emphasize the dangers of “bad” technical debt. But the previous section might have added some confusion, if those examples are of good technical debt, what is bad debt? Short answer, all of the previous examples, left unmanaged.
I could write a book series with examples of bad technical debt I have read about, or observed first hand, but instead, let’s focus on the fragile line separating the good from bad debt. An organization might transition from good to bad debt due to market pressures, organization changes, or simply time.
If no organization is immune to technical debt and the line between good and bad debt is fragile, should you accept debt as a necessary evil, a cost of doing business? Not necessarily, there are strategies for dealing with technical debt, and they are more practical than you might expect.
The beauty of the debt metaphor is that it helps explain the issue, and offers insights into handling it. For the remainder of the article, you can mentally swap “technical” for “financial”, the concepts translate either way.
Where should you start? How do you know how much technical debt you have, and how much of it is bad? Start by doing an assessment, document your debt, assets, and options. Address the short term problems, then focus on a long term technical health journey.
At the core of a technically healthy organization is the culture of spending prudently, and planning ahead. But culture takes time to develop, and the larger the organization, the more difficult it is to rely solely on it. I believe that process and automation are key to developing and maintaining such culture. Following are some examples of process and automation I have seen work:
The list is not exhaustive, some steps will depend on your organization, industry, geography, etc. But the point is that it’s not difficult to get started, and the payoff is greater than you might imagine.