It's Called Technical Liabilities, Not Technical Debt

DZone 's Guide to

It's Called Technical Liabilities, Not Technical Debt

Technical debt has become a buzzword, but as Allan Kelly suggests, the metaphor shoud be retired and replaced with a small change that yields big implications.

· Agile Zone ·
Free Resource

Wherever I go, I hear developers talk about technical debt. Unfortunately, the expression isn't used in the way that Ward Cunningham originally intended it to be.

The time has come to retire the technical debt metaphor. In its place, we should talk about technical liabilities. This is a small change in language with big implications.

The big problem with talking about debt is that debt is not necessarily a bad thing. Debt is often good, particularly in a business context. This leads to misunderstanding between engineers and non-engineers and can even lead engineers into poor habits.

To many people in business (and particularly bankers), debt is good. Debt allows you to grow your business and improve earnings. When an engineer says, "this will add technical debt," the engineer thinks that they are warning about something bad, but to a non-engineer, debt is often the preferred form of funding. So, buying new capability with (technical) debt sounds like a good deal.

Let me go a bit deeper.

The essential part of Ward's explanation was this:

"There were plenty of cases where people would rush software out the door and learn things but never put that learning back into the program, and that by analogy was borrowing money thinking that you never had to pay it back."

However, the metaphor has been widely interpreted as something you might intentionally do. Debt thinking goes like this:

“We are (time and money) poor, but we can borrow from tomorrow’s riches, rather than write good code today we can save time (and money) by just getting something that works and later (when we are rich) we can come back and do all that good stuff which we should do. (And by the way, if it turns out that our initiative fails then we have saved effort and money.)”

This thinking is ripe both among developers and those who employ developers.

This kind of debt thinking is, perhaps, similar to a mortgage:

"I don't have the money to buy a house right now, but if I borrow the money from a bank, I can pay back the money over time with the money I save on rent."

Yet, many engineers are the first to bemoan the fact that despite the best intentions they never get to pay back the debt. Instead, they merely service the debt. That is to say, they (at best) pay the interest but never the principle debt remains. Indeed, all too often the payments are not even sufficient to pay the interest which gets added to the principle.

With any debt, the important question is: can you afford the payments? The bigger the debt, the higher the interest rate and the greater the amount of today's resources (time, money, effort) that need to be devoted to servicing the debt. Yesterday, you borrowed so you could buy something beyond your resources. Today, you must devote some of your resources to pay those who provided the loan.

Over time "technical debt" massively hinders the ability of organizations to change both the software and themselves.

Technical debt is less more like a pay-day-loan than a mortgage: A loan you take when you have no choice, the high-interest rate can be crippling, payments eat into your ability to do any useful work.

Only those who are desperate and/or financially naive would accept a pay-day-loan. Let me suggest those who willingly take on technical debt similarly desperate or technically naive.

This logic is why I say: There is no such thing as quick and dirty, only dirty and slow.

So, talking about technical debt is loaded with problems, when is a debt good? when is it bad? what is the interest rate? do those who advocate incurring debt know what they are saying? And do you have a repayment plan?

Simply changing our language from Technical Debt to Technical Liability removes these problems.

Liability is something neither business and technical folk consider good. If I look at my dictionary it tells me:


1. Subject to an obligation

2. Exposed to a possible risk.

3. Responsible for...

...and some more."

These attributes, both in a technical setting and non-technical context, can be agreed by everyone.

Businesses have to list liabilities on their balance sheet and reducing the liabilities produces a more attractive balance sheet. (Debt, on the other hand, is listed as an asset on bank balance sheets, and even Apple sometimes chooses to issue debt rather than use capital.)

Let us let "technical debt" go back to Wards original meaning. Let's talk about technical liabilities in our systems.

Technical liabilities that cost us because they create obligations that slow us down, obligations which must be repaid; and they create risks, we don't know when an obligation is going to bite us.

agile, finances, technical debt, technical liabilities

Published at DZone with permission of Allan Kelly , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}