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, it is kinda too simple though. A few have thought a more catchy metaphor 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 on Twitter:
For this to be technical debt there would have needed to be a benefit somewhere else. Otherwise, it's just technical damage. https://t.co/FsWKnDUFGV— Gregory Brown (@practicingdev) March 26, 2017
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, 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 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 though 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, 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 it’s peak valuation was billions.
All is not lost, though
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.
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.
blog comments powered by Disqus