Technical Debt as Metaphor for Future Cost

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.

A counterpoint to this – I recently saw a talk by HomeAway’s CEO, Brian Sharples (at Capital Factory). I also had a chance to talk to one of their lead developers (a friend of mine from way back). When I asked my friend how it was going these days, he said (paraphrased) “we’re paying down a ton of technical debt right now… and when I look back, and ask if we should have done anything different, the answer is no. I think we made the right call.” Interesting. Thanks to Eric Ries, I knew what he meant by Technical Debt. I also knew what he meant about paying it down (HomeAway has been acquiring companies, and paying it down in this context means they are consolidating these companies onto common software systems instead of maintaining fragmented systems… )

In their terminology, technical debt is a cost that has to be paid in the future. It can be estimated in terms of work effort. But consider a variable interest rate – you have the same problem. You estimate costs, but you don’t know for sure what the future cost will be.

Finally, I actually heard the CEO refer in his talk to paying down technical debt. He had the same meaning the developers had. What this told me is that he’s invested in the whole company, not just the “business part” of the company. Those techies are his people too, not just an IT arm to be offshored later. And they explicitly understood they were postponing a cost (integration) into the future, a future in which they could afford to pay it down (IPO money helps with that).

Dave goes on to say:

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.

Getting a handle on the cost (future cost) of technical debt is hard, but it can be done. You usually have an ongoing cost that you can think of as interest (the cost of maintaining two systems, for example, or supporting two databases when you only need one). When you remove one of the two systems, it may have a lot of accumulated debt- which is now all retired debt. Presumably its functionality was either no longer needed, or replaced by implementing (and paying for) another system.

As to quantifying – this all comes down to estimation and convention. A proxy is just lines of code (each line of code incurs some maintenance cost, in theory). Another proxy is to put work estimates against it and cost those.

One might expect me to come down against metaphors – I’m not a fan of using them as proof in arguments or debates. They’re better used to explain yourself or your thinking, than they are as “proof”. But in this case, technical debt is a decent short-hand for work-effort we need to plan for in the future. It avoids people thinking they’re avoiding cost when they take shortcuts – they’re really just spreading that cost out over a longer period of time (for perhaps a much higher overall cost). Similarly, it assigns cost to gold-plating the software implementation (more lines of code = more debt).

Pretty interesting perspectives on the concept… for more about applying this concept to processes, check out these posts.