Paul Hammant's Blog: Tech Debt - Balance Sheets

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, I think it is a little too simple. A few people have thought about more catchy metaphors over the years. One was Steve Freeman with “Unhedged Call Option” (2010). He was citing Chris Matts and there was quite a conversation on his blog afterward. A week ago Gregory Brown on Twitter:

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 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, random factors 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.

Travelocity

Travelocity’s demise was in part because it hadn’t paid off its technical debt (2014). Sure that article skims on the technical issues, but they were there. It is said that Travelocity adopted “Apache Struts” in 2003 - a major architectural server-side web technology for the Java ecosystem. Here is a 2005 article wondering if Struts was going away (that also mentions Travelocity). The rumor is that Travelocity never removed that key legacy technology. By 2010 (give or take), the the softwre intdustry moved to client-side technologies and away from server-side technologies for web apps. Struts wasn’t just a opinionated server-side framework that didn’t forsee the client-side era (see my previous web architectures 2012 blog entry), it was a bad server-side framework when compared to dozens that emerged immediately after its creation for Java, and the hundreds of web frameworks for all languages.

Travelocity was ultimately sold for $280M to Expedia in 2015. Its peak valuation was billions.

Even if you do know you’re in debt , you hope loans are all low interest

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 that should be manageable in a low-interest situation.

Some loans are not low-interest though, and you are making a mistake if you think they are. Some people knowingly get in with loan sharks (and higher inerest rates) in moments of desperation and hope they can avoid broken legs outcome by paying the debt off on time.

At some point for a bad loan situation, you realize that full repayment is a priority. So you shift some focus other valuable activities to stressing about the debt.

What’s clear is that it is not easy to know the interest rates and period of repayment for loans towards tech debt.

So tech debt isn’t in your name - it is in your employer’s name

You yourself can always quit a job to escape technical 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 developer or IT professional. 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 people never ask for a balance sheet from software-writing groups that would show such debt, so value calculations are always optimistic. They should do though - software teams should maintain a balance sheet that enumertes all tech debt in the codebase. That would be a table of items that includes the cost of remdiation and how that compounds over time if not remdiated. Addtions to it should cause notifications to the finance team so that the value of the asset (the software app/solution) can be updated constantly. An attempt should be made to descibe the debt in laymans terms too. That in addtion to links back source that identidy the debt in detail for tecnicians.

Teams not refactoring as they go

With IDEs that support refactoring, you can face something that could be high-interest or risky debt, and eliminate it a commit immediately after a functional deliverable (or in the same commit). At least you can 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.

Teams not thinking of ‘craft’

Steve and Chris were interviewed for InfoQ magazine in 2014. The 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 again to the rust metaphor again. Prevention of rusting, that is. Or prevention of rot with varnish, etc.

See also

Published

April 7th, 2017
Reads:

Categories