Alt + E S V

Technical Debt: an Incomplete Metaphor?

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit


Source: NOAA

I recently attended ÜberConf, a conference geared towards Java/JVM developers. While the event was primarily comprised of workshops and technical sessions, one of the highlights for me was Janelle Klein’s session about bridging the technical-business divide, “Stop Getting Crushed by Business Pressure.”

In this talk, Klein shared some common sources of business-technology team misalignment and then offered suggestions on how developers can more effectively respond to these patterns. My favorite takeaway came from her discussion around the shortcomings of using ‘technical debt’ as a metaphor to communicate with business partners.

Klein’s argument was that managers care more about risk than interest payments. While her presentation is the basis of my thinking, I expanded her theory in an attempt to explore potential sources of the metaphor’s shortcomings. The following is not intended to discard the concept of technical debt, but rather an attempt to compare technical debt to financial debt in order to scrutinize whether the differences in the two concepts leads to miscommunication.

What is technical debt?

The now widely used technical debt metaphor was coined by Ward Cunningham back in 1992 to help communicate the trade-offs between finding a workable short-term solution as opposed to taking longer upfront to build a more optimal solution. The heart of the comparison is that these current trade-offs create future obligations to be repaid. Taking on technical debt comes with ‘interest payments’ – the cost of future rework that will eventually be required to correct and optimize the code.

As Martin Fowler described it in 2003:

In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest (i.e. expend more in future development cycles), or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

Technical debt is not always a bad thing. As Cunningham puts it in this 2009 interview,

“With borrowed money you can do something sooner than you might otherwise, but then until you pay back that money you’ll be paying interest. I thought borrowing money was a good idea, I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.”

As Cunningham references, the trade-off can absolutely be the best choice in certain circumstances, as when building a proof-of-concept. However, as Fowler documents in his technical debt quadrant, not all debt is created equal; you can also take on debt inadvertently and recklessly. Common project pressures, like last minute changes in scope or insufficient/shifting timelines, can lead to poorly considered compromises between current features and future burdens.

The technical debt metaphor is long established and widely used. It can be a good starting point for discussions with business partners, yet Klein’s experience has shown the analogy is often insufficient to drive her point.

What is financial debt?

“The essence of metaphor is understanding and experiencing one kind of thing in terms of another.”
– George Lakoff, Metaphors We Live By

Developers often use the technical debt metaphor to help communicate complicated trade-offs to non-technical counterparts. Making technical discussions digestible is a crucial element to effective communication, but it’s only the first step. By choosing ‘debt’ as the abstraction point, you also need to consider how your audience is likely to perceive and understand financial debt in order to compellingly communicate about technical debt.

Here are some things to consider about financial debt in relation to the metaphor:

1. Businesses run on leverage.
Mortgages, bonds, accounts payable, deferred revenue: debt in its various forms is a vital part of operating a business. It is seen as a financial tool that keeps the business running both in the short- and long-term.

Ratios are a key tool for assessing financial positions. The business worries about things like liquidity levels and debt coverage. (If you’ve ever applied for a mortgage and had the bank calculate your loan-to-value or debt-to-income ratios, you’ve experienced ratio analysis.)

The mere existence of financial debt is not in and of itself concerning. The amount of leverage the business incurs matters in relation to other metrics (assets, income, operating cash, etc); it also matters in relation to historic performance and industry benchmarks.

Think about leverage as a ratio when you frame your conversation around technical debt. The fact that you’re generating interest payments is not enough to create concern. Debt matters relative to your ability to pay it.

While you may not be able to provide a numeric technical debt ratio for the discussion, providing the context of how this project fits into the organizational’s operations and overall leverage is a crucial element to telling the debt story effectively.

2. Debt is largely viewed as a predictable financial instrument.
While the term ‘debt’ encompasses numerous types of liabilities, most business partners will come to the conversation using a standard loan or bond for their mental model. This type of debt is characterized by the following features:

  • a known amount borrowed
  • a known repayment timeline, typically with repayments occurring at regular interval
  • a known interest rate

Contrast this with technical debt. Are you able to communicate with any degree of certainty:

  • how much rework will need to be done?
  • how long the project can be sustained in its current state before things will need to be redone? when will interest payments be required?
  • how much it will cost the business to make this trade-off?

While we can make estimates for tech debt, they are generally much more abstract and subjective. In other words, most business partners will approach conversations about debt as an understandable instrument with a known cost. Technical debt, on the other hand, is significantly less predictable.

3. The time value of money (TVM)
TVM says that money in the present is worth more than money in the future. Imagine I owe you $100. Would you rather have that money today or next year? Of course you’d rather have it today. If I want to borrow the $100 until next year, I need to pay you enough interest to outweigh the opportunities you forego by loaning me that $100.

In other words, my willingness to make future interest payments to you grants me the opportunity to use the $100 now; from your perspective, you are willing to loan me $100 in order to receive future interest payments.

TVM is at the core of investment decisions, and it will thus be at the core of how business counterparts interpret discussions around interest payments.

Let’s translate TMV to tech debt.

Your business partner wants to the project delivered now. You tell them that creating a quick solution today is equivalent to borrowing money (resources) and will require the company to make future interest payments (rework or future missed opportunities due to cumbersome architecture.) They say, “interest payments later in return for a deliverable now. That doesn’t sound so bad.”

Part of the problem in communicating technical debt is not that your business partner doesn’t understand that you’re making a tradeoff, but rather that the business expects to have to make interest payments. Exchanging payments in the future in return for something now is the heart of TMV. Interest is a cost of doing business.

As with leverage, the existence of interest payments alone does not capture attention in the business world. Interest rates can catch their attention, but as we outlined above can be difficult to quantify.

4. Financial debt is contractual.
While there are always exceptions (e.g. bankruptcy or debt restructuring), as a general rule once money is borrowed it needs to be repaid.

Technical debt decisions are rarely all or nothing. Technology patterns shift. Budget availability expands and contracts. Projects’ prerequisites/dependencies adapt. Companies’ strategic prioritization re-aligns. Executive leadership turns over. Decisions change.

As these elements shift, project choices that made sense before may no longer make sense now. People on both sides of the discussion have seen these patterns play out, and they understand that project status is a tenuous thing. Just as technical debt can be paid down, projects that were once foundational may be abandoned for new solutions; there is no rule that once technical debt is incurred it must be paid back.

A discussion about technical debt is fundamentally a discussion about asking a manager or business partner to ignore the siren song of the current budget cycle/managerial demands in favor of a longer-term outlook. These types of decisions are hard for individuals, especially in the face of a complex system of unknown unknowns. This dynamic can make technical debt a more emotional topic than financial debt.

Why does this metaphor fall short?

In short, your business partner is likely trained to view debt as essential, predictable, and relative. Managers and business partners care about effectively leveraging resources to deliver results now, and they likely understand debt as a valid tool to accomplish this, especially when the future needs are uncertain and technological solutions are evolving. If you don’t recognize that frame of reference, it will be difficult to craft a metaphor that resonates.

As Klein states, “managers don’t care about technical debt interest payments.” If you’re trying to argue against incurring technical debt, you must add the context of risk.


Source: Janelle Klein

The takeaway: don’t just focus your technical debt discussion on future interest payments. The gradual loss of predictability is scarier to business partners than the gradual increase in cost. In as much as you can quantify and contextualize the cost of interest payments, do. Sometimes cost alone is a sufficient motivator. However, your argument against technical debt will be strengthened if you focus on helping your business counterpart understand how decisions today increase future risk. Talk about the loss of predictability in the project. Show how compromises now leads to performance degradation later.

As part of the dialogue, an audience member suggested that perhaps a better metaphor might be comparing technical debt to an unhedged position in the stock market. It’s definitely a less accessible metaphor from both sides, but I liked the attempt to find an analogy that focused on the potential for unmitigated risk. Whether you try a new metaphor or adapt your approach to talking about technical debt, Klein urges you to focus on your storytelling around risk rather than interest.

7 comments

  1. Thx for the analysis! I completely agree. (And I also like Janelle’s approach. Her “Idea Flow” is one of the best books I recently read.)

    The Technical Debt metaphor is not helping to understand what’s going on, why the underlying symptom actually exists (“legacy code”, “brownfield code” etc.). More explanatory power comes from another metaphor, I think. We’re not dealing with debt, we’re dealing with addiction: http://geekswithblogs.net/theArchitectsNapkin/archive/2015/07/22/there-is-no-such-thing-as-technical-debt.aspx

  2. […] published a great article today on the incompleteness of technical debt as a metaphor. This touches on a number of points, the best one I think is that for many people in […]

  3. All metaphors fall short at some point, depending how far you take them. I think technical debt is a great metaphor but of course you need to elaborate on the details when explaining the concept to a business person, something I do regularly as a consultant.

    It’s of course impossible to quantify, but if not contractual technical debt can at least be somewhat formalized. For example take a project where cost is split 10/90 over its lifetime with 10% of the cost before initial release. The initial work was poor causing ongoing development tasks to take on average three times the effort compared to if the code was clean. Now say we spend twice the time up front making the code clean, the rest is just simple math 10 + 90 = 100, 20 + 30 = 50. We just cut total cost in half! On a large project this could be hundreds of millions saved. This example usually gets through to business people very well, an interest rate of 200% is something you want to avoid.

    I always end off explaining that there is no actual debt and use a second metaphor, the messy kitchen, bringing spects such as quality, craftsmanship, pride, risks into play.

    I’m actually right now helping a client with some work that could have been done well within a single day but that’s taken me several weeks because their code is an incomprehensible mess.

  4. Really like this article.

    Wonder if the idea of technical debt is becoming more redundant with agile and cloud.

    Comment would have been too long, so wrote a blog response.

    https://medium.com/@PaulDJohnston/the-term-technical-debt-is-25-yrs-old-3f8c92360278

    1. I really like the shift the focus from incurring debt to incurring risk. Depending on the way that technical debt is incurred, you might be borrowing from an established bank with known payment plans, or you might be visiting a pawn shop or loan shark where the full payment may come due at any time. Consider how technical debt comes due immediately when a security issue is discovered.

      There is another area of technical debt that I feel needs redefined. Many times we have products that were designed well and continue to work, but they have not been updated. I see this as technical depreciation not debt. They don’t have the latest features, but there was no trade off made during development to incur debt. The best solution rarely stays the best solution.

  5. Fantastic analysis. I have often found myself not just using the term technical debt, but even applying it in an even wider array of contexts…probably when more clarity about the tradeoffs at play would improve the analysis *and* the communication about the issues. Great reminder about what other people are hearing!

Leave a Reply

Your email address will not be published. Required fields are marked *