Today, I happened to run across this 2009 Eric Ries' article on technical debt. It’s a longish read but thoroughly worth the investment.

I have seen the idea of technical debt used in a number of teams and with varying degrees of utility. While I find it a powerful metaphor, I’m not always a fan of its implementation.

What is technical debt?

If you are not familiar with the concept, technical debt is the idea in software development that deadlines, business needs or time pressure might force an implementation that is not as well designed or thought-out as the technical team would like. As a result, ‘technical debt’ is created. The project can move on but the maintenance cost of that code will be higher than normal – you are paying ‘interest’ on that investment.

You will continue to pay that interest until pay down the principle of the loan by refactoring the code into a proper solution.

In most cases, the concept of technical debt is used by a technical team trying to make explicit to business stakeholders the longer-term costs of taking shortcuts.

Eric does a good job of discussing how agile or lean practices can minimize the impact of technical debt, how some debt is ‘good’ since its unlikely to ever be repaid or is a good investment on the future and, most interestingly, how the idea of technical debt runs counter to several other technology principles.

The Problem with Metaphors

For me, the perspective that is missing from the technical debt discussion is the communication issue.

I would put the problem this way:

The fundamental metaphor underlying technical debt is easily understood in technology circles but nearly incomprehensible outside of them. Unless you understand in detail the technical trade-off you have no appreciation for how you are ‘borrowing’ which makes it a trust issue between the business and IT teams. If this trust exists, then you don’t need the metaphor to make the problem explicit. If the trust doesn’t exist, then the metaphor won’t help you.

The reason the metaphor doesn’t hold is that the unit of borrowing can’t be quantified. Technical debt is an attempt to use the well-understood concept of financial debt to explain a software development problem but everyone (business and technical) understands what happens when you borrow money and the cost of that decision. It’s explicit.

If you borrow $1, well then the amount you owe is $1. People have mortgages and credit cards and use them to make decisions to borrow money so both everyone in an organization can be reasonably expected to understand the basic concepts of financial debt.

The same is not true of technical debt. The unit of measurement is entirely a trust issue between people. Most technical debt conversations are really the engineers saying to the business stakeholders: If you make me do it this way and in this timeframe, it will cost you more in terms of effort to support per month.

But, unlike the financial debt, the interest may not materialize. On your mortgage, you know exactly how much interest you will pay. It’s not a random number.

Brand equity is the reverse metaphor: It’s a concept that resonates well in marketing circles but almost holds no weight in technology teams who usually consider it nebulous and somewhat illogical. For a great discussion of this perspective, read I’m Feeling Lucky: Confession of Google Employee number 59. In it, Douglas Edwards chronicles his struggle as the ‘brand guy’ working in Google’s notoriously engineering driven culture.

Brand equity is the same trust issue between people. It’s the marketing team saying to the engineers: build this tool to create brand equity and that’s a good thing in a way that I can’t really quantify for you but it’ll work out.

It’s all about the Context

The usefulness of the technical debt metaphor all depends on the context. On Friday, I’ll look some ideas how to use these metaphors correctly and when they create more harm than good.