The CIO-CFO Conversation: Technical Debt—An Apt Term?

Sometimes we technologists can be a bit too clever for our own good. The term technical debt, attributed to Ward Cunningham in a 1992 OOPSLA conference speech¹, may be an example. We use the term often these days, generally in the context of justifying investments in nonfunctional aspects of IT; that is, investments intended to improve the internals of IT systems, rather than to add new user-facing IT capabilities. Such nonfunctional investments, unsurprisingly, can be difficult to explain and justify. The term technical debt has seemed like a good way to communicate this need “in the language of the business.”

Unfortunately, many CFOs seem to hate the term.

I think there are a few good reasons. Among them: technical debt has come to mean just about anything that technologists believe requires an investment whose value is not obvious to the rest of the business. It can sound like a condescending way to say to the CFO “these are the things you’ll never understand but have to give us money or allocate time for.”

Technical debt is a metaphor, and, like any metaphor, it sorta fits the situation and sorta doesn’t. The concept itself is useful, drawing attention to the important fact that internal attributes of IT systems create risks and opportunities and generate costs. They determine just how agile and resilient an organization can be, as well as how productive each marginal dollar of IT spending can be.

The term was coined to force discussion about decisions we make, under time pressure, to take shortcuts; the point is that there’s a cost to those shortcuts, even if they seem free in the moment. Yes, the work can be ready more quickly, but future work will be slowed down by the deficiencies in the code and architecture. That future slowdown is the “interest” on the debt, and it will continue to be incurred until the debt is paid off by spending the time necessary to improve the internals of the system.

Nice metaphor! But, then, should unintentional deficiencies in the code also be considered technical debt? They’d have precisely the same consequences, right? (That is, interest payments until the debt was paid off by refactoring.) Then, how about those cases where code was written before the final architecture jelled? What if the code seemed fine when written, but after learning more during the development process, the developer realizes that there’s now a better way to write that code, or that it’s inconsistent with the final design of the system? Well, perhaps that counts too, since it may incur interest payments until it’s paid off. How about if there’s a patch or an upgrade to an underlying platform that hasn’t yet been applied? Same result, right? What if a new technology or product becomes available that’s a better solution to the problem? This one’s a bit more subtle—the company’s interest payments on this are more along the lines of an opportunity cost rather than a cash or time payment.

Early users of the term wanted to make the point that there isn’t a free lunch—if you want to take shortcuts, you’ll still have to pay for them later, with interest. Today the term is often used in the extended sense: the hidden things inside software systems that demand interest payments until they are paid off, whether they resulted from taking shortcuts or not.

Should technical debt be defined as deliberate “borrowing” of time to get to a faster release? Or should it be defined as those deficiencies in the internals of our systems that will cause future costs (the interest payments) and risks? Do we define it in terms of the cause—borrowing time—or the current state, as a snapshot, of what will cause drag in the future?

There are plenty of opinions on the subject, but I’m not sure they’re relevant to our discussion of CIO-CFO conversations. In that context, it doesn’t matter how the debt was incurred, just how it impairs the IT asset today. We care about what risks and costs that deficiency generates, and whether we should invest in improving the asset. It’s the snapshot view that matters, not the historical view.

To sidestep the debate on terminology, I’ll just define a new term to use here: technical delta. Your technical delta is the different between the internals of your systems today and the ideal internals of your systems for that same functionality. I like to pair it with another term—the functional delta of your systems, which is the difference between what your systems currently do and what they would ideally do to move your business forward (think “workarounds” and new capabilities the business needs developed). The functional delta is apparent to people who use the systems; the technical delta is only apparent to those looking at their internals.

Both the functional delta and the technical delta are important in the CIO-CFO conversation, but it’s the functional delta that typically gets discussed and invested in. CIOs lack a language for explaining technical delta and communicating the business case for investing in it. And so we’ve appropriated the concept of technical debt, thinking that it will impress CFOs, but instead, it irritates them. Why?

First, there’s the opacity of the term. A CFO wants to know what the company’s investing in and what return will come from it. Investing in paying down technical debt sounds like “investing in stuff you don’t have the technical skills to understand.” It might be true, at one level, but that’s not enough of an investment case for a CFO who has a duty to make sure the company’s money is well spent. It’s sort of a sledgehammer approach, or a gun to the head of the CFO demanding a mysterious payoff. Of course, the CFO needs to trust the CIO—who, after all, is the technical expert—when it comes to technical details, but the question here is how to build that trust.

Second, while debt must be paid off, “technical debt” need not. With technical delta, there’s a real business decision to be made about which parts of it should be paid off. Real debt is shown on the company’s balance sheet because it’s a true liability, an obligation. Technical delta, on the other hand, isn’t owed to anyone; while it may be an economic liability, it isn’t dollar-for-dollar a liability, since only some portion of it will wind up being paid off. Arguably, it should show up on a balance sheet (as I said, an impairment of the asset), or at least as a note in the financial statements or a risk factor in the 10-K. But even if it did show up on the balance sheet, how would you assign a dollar value to it? Again, calling it debt makes it sound to a CFO’s ear like a demand that it be paid off.

Another place the metaphor falls apart is in how much interest the delta incurs. If the technical delta affects the maintainability of the code but happens to be a system that rarely needs to be changed, then the interest rate might effectively be zero. If you’ll never need to change a software system, it doesn’t matter much that its variables are poorly named, for example. On the other hand, if you’re making changes every day to a system, then the poor variable naming will slow you down and lead to errors.

Another difference is that replacing an old system with a new one might in one stroke wipe out all of the debt (yes, you could say that’s a little like a bankruptcy, where the old system is declared to have no value—but that’s pushing the metaphor a bit far!).

So technical debt may sometimes be an unhelpful metaphor. Nevertheless, it points to something real that CFOs and CIOs need to jointly address.

There will always be tech delta and functional delta, simply because the world changes. There’s constant change in consumer preferences, competitor activity, technology, regulation, geopolitics, climate, health conditions, and security threats. For all the reasons that the digital economy requires continuous change from a company and therefore from its IT systems, technical and functional deltas must constantly appear. They may be closed soon after they appear or much later, or never at all.

A fundamental IT strategy decision is which of these deltas to close—then when, and how. In a way, it’s the only IT strategy decision; we invest in new IT systems based on functional deltas, and we choose to maintain systems (“keep the lights on”) that are still addressing functional needs. Investments can be justified by their impact in closing either a functional delta or a technical delta; both are valid reasons, both sources of business value. But importantly, to discuss the case for closing a technical delta, the CIO must have already communicated that the delta exists.

I’ll discuss the challenge of communicating the status of IT, with all of its deltas, in an upcoming blog post. In the meantime, my advice for CFOs: tech delta poses real costs and risks. And they are not necessarily anyone’s fault (they arise even from good decision making). It’s often risky to carry tech delta because the company will not be able to quickly or effectively seize opportunities, respond to competitive threats, or react to sudden disruptions like today’s pandemic. You should work with the CIO to understand where there’s tech delta and functional delta, and make a plan for addressing them.

Here’s my advice for CIOs:

• Communicate with the CFO about the status of the company’s technology asset, including tech delta and functional delta, and show what impact these will have on the company’s future and on its risk posture today.
• Don’t accept that your conversations with the CFO will only be about budget, and don’t budget only for keeping the lights on and functionality-related initiatives.
• Make the CFO aware of risks and limitations on agility. In some cases they should even be disclosed to investors and other stakeholders.

I’m not ready to drop the subject of technical debt quite yet, though. Code should be maintainable, scalable, resilient, simple, well architected, and secure. Increasingly, we think about these as quality attributes rather than bolt-ons. Just as we don’t deploy code to production until it passes its functional tests, we shouldn’t deploy it if it doesn’t pass its nonfunctional tests. It’s much cheaper to build quality in than to add it later. In fact, code that’s weak on any of these dimensions, especially maintainability (readability, etc.), is going to start costing you “interest” immediately, if you’re doing peer code reviews. Today we should rarely incur these kinds of technical deltas because our bar for quality—and what constitutes “finished” code—is higher. And because there’s rarely a trade-off between quality and speed—for example, writing poor unit tests will slow you down, not speed you up. Choosing good variable names similarly helps you go faster.

Deliberately incurring technical debt made more sense when we did big, monolithic releases. In the rush to a release—the chaotic period right before the big-bang deployment—there was pressure to cut corners. But with continuous delivery, deliberately leaving behind technical debt approaches insanity. As a former software developer, I know that developers don’t want to interrupt their “flow” to deal with some of the nonfunctional attributes. Nevertheless, as extreme programming prescribes, after you’ve “flowed” to a solution, you can then step back to refactor and simplify.

So perhaps the original meaning of tech debt is becoming less relevant. But the concept of tech delta becomes more relevant as agility and resilience become more important. Certainly it’s an essential topic for the CIO-CFO conversation.

—Mark
Twitter | LinkedIn | Blogs | Email

More on this topic

The CIO and CFO Conversation, Mark Schwartz

The CFO and CIO: Partners in Success, Mark Schwartz

Financial Liberation: Taking Control of Costs in the Cloud, Phil Le-Brun

Decisions at the Margins, Mark Schwartz

Footnotes

1. Letouzey, Jean-Louis and Whelan, Declan, Introduction to the Technical Debt Concept, Agile Alliance, 2015;
   Fowler, Martin, Technical Debt;
   Kim, June, and Wang, Lawrence, Ward Explains Debt Metaphor, WikiWikiWeb.