The grandpappy of modern programming, Ward Cunningham, coined “tech debt” for situations where the codebase should be refactored or improved before moving on to new work. As a metaphor, it is a little too simple though. A few have thought of more catchy metaphors over the years. One was Steve Freeman with "Unhedged Call Option." He was citing Chris Matts and there was quite a conversation on his blog afterward. A week ago, Gregory Brown said on Twitter: "For this to be technical debt there would have needed to be a benefit somewhere else. Otherwise it's just technical damage."

Hmm, that is interesting. It feels like debt is something that can be paid off anytime, yet technical damage builds up, and compounds in very visual ways (like a rusty chain on a bicycle), perhaps leading to a calamitous failure. Damage hints at the inevitability of dilapidation following neglect. Or it hints at the accretion of layers of bad stuff - like cholesterol in hardened arteries.

Before we go too far, here is Ward on video in 2009 on the debt topic:

Anyway, I think debt is the right metaphor after all, and with DevOps as an encompassing practice, we are able to say that technical debt can occur anywhere - databases, environments, firewall configurations, silicon, shared services (between environments), etc. Oh, and the missing scriptability and elasticity of those, specifically.

But there are caveats, randomness, and a balance sheet of multiple debts, I think:

You Don’t Always Know You’re in Debt

Specifically, of the hundreds of little loans you’ve taken out in a codebase, your skill/experience/tooling may mean that you can’t recognize many of those little loans.

If You Do, Think You’re Taking out Low-Interest Loans Exclusively

When debt is via regular loans, it should be structured and predictable. In a period of time where interest rates are low, you expect structured, predictable, low-interest loans. You understand that interest has a compounding effect, but it should be manageable in a low-interest situation.

Some are not, though, and you are overconfident to expect that all should be. Again, skill, experience, tooling, and possibly chance may prevent you from knowing which debt situations will quickly and silently transform into loan-shark style ones that are hugely problematic. You may have thought you had two years to pay off that loan at low interest rates because that is what the market is doing presently, but not so in some cases. Even when you thought the terms were clear up front, some of those loans have been secretly resold to the local break-your-leg mob and had those terms changed. Now repayment is a priority, and at high-interest rates, is changing your focus from throughput of value to stressing about the loan.

Debt Isn’t in Your Name, It Is in Your Employer’s (Most Likely)

Broken legs? Not really: you can always quit that job and escape this debt completely. The Inc/Llc/Ltd/Plc is where the debt stops. That loan shark is going to break someone else’s legs - a whole company (companies are people too!). The stock market could savage their valuation but not yours. You just move on to a new job - you’re indemnified.

Really, though, you should have no authority to silently accumulate debt as you are not the CFO.

Given your ability to escape the debt and the uncommunicated nature of the loans and their interest rates, you have robbed the CFO of part of their job - budgeting software delivery and the multi-year costs of ongoing ownership. The CFO had the authority to put the company in debt (for the board), not you as software/IT  professional  careerist. Of course, there were plenty of others encouraging the repeated debt-embracing habits, including non-technologists in key roles, so it is not all on you.

Finance thinking people never ask for a balance sheet from software writing groups that would show such debt, so value calculations are always optimistic. They have an impact though. For example, some part of Travelocity’s demise was because it hadn’t paid off its technical debt. It was ultimately sold for $280M but its peak valuation was billions.

All Is Not Lost

With IDEs that support refactoring, you can face something that could be high-interest or risky debt, and eliminate it in the same commit or immediately after- at least, in the same cycle as the creation of the apparent value that was asked for in the story/task. Indeed, IDEs (like Intellij) can be so good at this that you can start to look at large changes as not risky, and not debt creating. You end up with refactoring as an ordinary team activity and a codebase that is “most stable." Of course, none of the finance or business people care today, as we’re not communicating a debt balance sheet weekly, but that could change, too.

Craftsmanship

Steve and Chris were interviewed for InfoQ magazine in 2014. They talk around the relevance of the ‘Unhedged Call Option’ piece. They finish the discussion with a thought about the software craftsmanship movement- a solid thought. It seems closer to the rust metaphor again. Prevention of rusting, that is. Or prevention of rot with varnish, etc.