Technical Debt is really Software Debt. And it’s a AAA-rated CDO…
I’ve long struggled with the Technical Debt metaphor. It was immediately useful when I first heard it. I still think it is useful, albeit as a starting point. The more I worked with software, the more infuriatingly incomplete it started to feel.
Some years ago I found myself in a rabbit hole, researching the 2008 financial crisis. It reminded me of other insane stories like Knight Capital, and farther back, about how Enron imploded (because Enron India’s meltdown was shocking, and destructive. And because a dear friend, in his past life, was on the team at Lehman Bros. that structured financing for Enron India. So come 2008, when Lehman imploded, I got to hear about the hard-chargin’ super-leveraged risk-takin’ days from someone who was there in the early days of the so-called Dick Fuld era. It was all very fascinating, but I digress…).
One source of my unease is that I think discussions of Technical Debt don’t sufficiently examine the nature of the Risk of the underlying challenge. The other is that the concept skews and pigeonholes the Responsibility part of the underlying challenge.
Down in the rabbit hole, a slow realization began.
Framing pigeonholes Responsibility. Software debt packages risk. We need better mental models of that risk. Software debt risk perception is muddied by personal bias. Software debt is rooted in complexity. We abhor complexity. Software debt is inevitable. Software debt always compounds. Software debt is layered. Software debt is networked. Software debt is like a complex opaque financial derivative. 1,000 words in 1 picture: xkcd summarizes it best. Note: In this post, I have software organisations in mind, viz. ones that exist mainly because of the software they make and ship (whether priced or gratis).
Read in full here:
This thread was posted by one of our members via one of our news source trackers.