Technical liabilities: not technical debt

(This is refactored version of my earlier blog post Technical Liabilities and not Technical Debt - its shorter and contains few of the references to banking and finance.)

Wherever I go I hear developers talk about "Technical debt". Unfortunately the expression isn't used in the way Ward Cunningham originally intended it.

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 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 habbits.

To many people in business - and particularly bankers - debt is good. Debt allows you to grow business and improve earnings. When an engineer says "This will add technical debt" the engineer thinks they are warning about something bad, but to a non-engineer business person, 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 Wards 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 to payments? The bigger the debt, the higher the interest rate the greater the amount of todays resources (time, money, effort) that needs 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:

"Liability:

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. Lets talk about Technical Liabilities in our systems.

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