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”.
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:
Good debt is acquired through prudent decision making, is well managed, and is usually cheaper to keep around by paying off the monthly installments, than paying off entirely
Bad debt is acquired recklessly, has high interest rates, is often unmanaged, and results in accrued interest exceeding the original principal and the value being delivered
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:
Deferred refactoring, at the cost of lower efficiency and higher infrastructure costs
Deferred automation testing, at the cost of larger testing teams and manual regression testing
Deferred modernization efforts, at the cost of relying on legacy systems or services with lower efficiency and higher maintenance costs
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:
Document what technical debt means in your organization. Make sure the list is succinct and does not change significantly over time
Introduce organization level tools for scanning, aggregating, and reporting on the quality of your tech solutions
Identify and collect key performance metrics (KPIs) for all tech-related work efficiency
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.