My last – frustrated – post finished with this line:
“banks are collecting technical debt the way they used to collect sub-prime”
I’ve always disliked the tech debt metaphor, in part because the way it is generally used is different to Ward Cunningham original defined technical debt and in part because those using it often have a simplistic understanding of debt – for example, credit card debt (which is generally to be avoided) is different from mortgage debt (which many of readers are only too glad to take on.)
A couple of years ago Chris Matts and Steve Freeman suggested a better analogy: an unhedged call option. While technically correct this metaphor required one to understand financial markets and options, most people outside the financial arena (and a good few inside it!) aren’t familiar with such concepts and so the idea floundered because the metaphor was more difficult to understand than the thing it was describing.
Still, Chris and Steve instincts were right, especially in financial arena’s the tech debt metaphor may be doing more harm than good. For a banker collecting debt is good… let me explain.
For you and me, as individuals, a debt is something I have to repay, it is a call on my future cashflow. For individuals – and many non-financial companies – a debt is a liability. As such we would rather not have it.
But for a bank a debt is an asset.
The bank holds the debt, when I take out a loan I promise to pay a bank sums of money in the future. Therefore my liability is their asset. It is two sides of the same coin.
Conversely, for a banker liabilities are things they own other people, e.g. my savings. When I place £1000 in my savings account it is an asset for me but a liability to the bank because the bank need to pay me £1000 at some date in the future. (Importantly, I decide that date and am unlikely to forwarn them.)
Bankers want more debt because debt is an asset. Debt is good.
So every time as software engineer says to a banker: “Doing it this way will create more technical debt” the banker hears “Doing it this way created more assets.”
One of the problems that occurred in the 2000’s was that banks found a new way to take on even more debt. The debt was packaged in technical ways “collateralized debt obligation” and “tranches” and such which allowed the banks to assume more debt. Things went well for a while and bankers believed they had found new way to make money. The problem was these debt packages were hideously complicated, so complicated in fact that many of those trading in these instruments didn’t understand them.
Nor did the banks own risk officers.
Nor did the regulators.
Does this sound familiar? Isn’t this technical debt?
What happened next made things worse: new instruments were divised by some of the people who didn’t understand how the original instruments were structured. In Fools Gold Gillian Tett tells of how the original JP Morgan team who devised these debt products warned as other banks introduced products which they could see didn’t make sense.
Doesn’t that sound familiar?
Doesn’t that sound like the Chief Engineer telling the Captain “She cannae take it, Captain” and the Captain doing it all the same? (Did Star Trek condition those in command to ignore the advice of their engineers?)
Banks aren’t unique here but their business model makes the problems more acute. Even outside of banking the technical debt metaphor has encouraged “debt thinking”, i.e. the idea that one can borrow from the future to get something delivered sooner and pay back later. This might be viable if we treated such debt as a mortgage which allows an asset to be purchased now in return for a long term payments plan.
However when programmers use technical debt to borrow from the future it is more like a payday loan which very quickly balloons and demands increasing amounts of our capacity (cashflow) to service the loan.
Banks are an extreme example of debt funded businesses. Most companies balance the amount of debt they take, if they need more money they may borrow it or they may ask shareholders. In general reasonable to see companies as getting half the money they need from shareholders and half from borrowing.
But banks don’t.
Banks may get less than 10% of their funds from shareholders, they rest they borrow. Anat Admati and Martin Hellwig in Bankers new Clothes explain this in detail but basically a non-financial company couldn’t do this because there is a high risk the company would go bust. But a bank can do it because in the event of failure they believe (and RBS proved) that the government will save the bank.
In other words: banks pile on debt because there is someone else who will save them if something goes wrong. (Economists call this “moral hazard.”)
It is a common business practice to borrow (increase debt) to improve returns so bankers aren’t alone in seeing financial debt as good but they are extreme.
So the question is: Do bankers believe they can take on technical debt because someone else will save them?
I can’t answer that question but clearly engineers view debt differently to bankers. Its more complex than a simple failure to understand.
Bank IT runs on a project model: as I say in #NoProjects this model encourages cutting quality because of goal displacement and the erroneous idea that it will be “done.” Even if bank managers don’t believe it will ever be “done” they can see their involvement ending, perhaps they are contractors, or perhaps they will move onto another “project.”
There are plenty of companies out there, be they outsourcers or tool vendors, who are only too happy to say their service or tool will solve the problem:
“Tech debt too high? No problem for Far Eastern Outsourcer No.1, we can fix it!”
“Do you suffer with long testing cycles? Then get Cyber Tester 3.0, it will find your bugs and shrink the cycle quicker than you can say contingent convertible bond”
As Willy Sutton is might have said: “I sell IT to banks because thats where the money is.”
So is there a way out of this?
Well, there is one more complication that might actually offer a way out.
Another dimension to banking is time: the loans that banks make (their assets) extend over the long term (25 years for a mortgage) and the bank have little power to force repayment. They are said to be illiquid – it is difficult to cancel an existing loan so you can’t turn a loan you have extended into hard cash very easily.
But, the deposits banks accept (their liabilities) are very liquid. I can get my money out of a cash machine at any time and leave the bank with less money – ever wondered why banks pay higher interest rates on fixed savings?
Some say it is this problem that banks exist to solve: turning short term liquid deposits into long term illiquid loans; matching assets and liabilities on different time scales. (Mervyn King has as interesting discussion about this in The End of Alchemy.)
When we build a software system we are building an asset.
The system itself – retail banking systems, trading platforms, risk management systems – are long term investments and become major assets. Some last decades but they are illiquid, changing systems is hard. RBS has recently aborted a demerger because of the difficult of building a new retail system (FT: RBS chief warns it may fail to sell Williams & Glyn this year).
Conversely, defects in these systems (bugs) and poor architecture (what is often called technical debt) are liabilities. More importantly, like banks financial liabilities, these can strike at any time. I can visit the cash machine today and an unknown bug can crash the system today. Similarly, a poorly designed sub-system – say there is a singleton in the system – might not crash a system but can slow down operations, enhancements and so on.
Sure these problems might not appear today, but they might, likewise I might not visit an ATM and withdraw cash today, but I might.
Therefore, let me suggest that we drop the language or Technical Debt. (Or perhaps let Technical Debt return back to Ward’s original meaning.)
Lets instead talk about Technical Liabilities:
Technical liabilities, in software, are sections of code, even entire systems, which because of their (poor) design are difficult to change, significantly hinder enhancement and are fertile ground for defeats. Such code often lacks unit tests and coherent design.
Such liabilities are highly liquid and problems may transpire at any time – impeding performance of the system itself or enhancements by programmers.
In building an asset some liabilities will be incurred. But,
- a) it is possible to minimise these liabilities while building and
- b) these liabilities can be reduced with investment.
Reducing the liabilities will make the asset more valuable itself and enhance the asset’s ability to change in future.
Replacing the words “technical debt” with “technical liabilities” is a small change to our language, one we can all understand easily, removes a poorly understood metaphor that is open to misinterpretation.
| Reference: | Technical Liabilities and not Technical Debt from our JCG partner Allan Kelly at the Agile, Lean, Patterns blog. |
