Reframe Technical Debt as Software Debt. Treat it like a AAA-rated CDO
8 points by adityaathalye
8 points by adityaathalye
The problem with "technical debt" as a metaphor is the debt part. It's a quantitative metaphor applied to a qualitative problem.
Money is fungible, i.e. any one dollar is identical to any other dollar. So you can carve up debt in any number of ways because the underlying content is isomorphic. This is categorically not the case with software problems.
Why does it matter?
Post author here: my whole PoV is, in fact, about the quality and nature of "debt"; viz. what it is made of... is it simple interest (a single unix tool), or compound interest (nonstandard flags across the unix ecosystem, but a dictionary lookup can mitigate confusion), or runaway complexity... complex opaque derivative containing all sorts of nonlinearities (any networked computer system, even if it is one client talking to one server).
And I'm arguing that software is very amenable to runaway complexity.
Sidelight: All debt is fungible, if one can make a market for it... people have traded debt for as long as debt has existed, long predating money. Ali owes Shekhar some quantity of saffron, Shekhar owes Annie some quintals of rice. Annie knows a rice lord who is drowning in it, but really wants some Saffron to make kheer and start a sweetmeats business. Now Shekar can make a market and solve everybody's problem.
The software industry equivalent of market-making for non-fungible debt, is the acquisition / sale, in all its many forms; acquihire, spinoff, wholly-owned subsidiary, "embrace, extend, extinguish".
The acquisition / sale attempts to financialise the total organisational debt. It is a bet that the ultimate payoff---how many ever years out it is, in time---will more than cover any losses over the lifetime of the acquisition. This includes money paid out as fines, class actions, restitution, defensive acquisitions (IP portfolio), bad markets etc.
The VC portfolio is another expression of this financialisation of non-fungible debt. The VC spreads monetary bets across a portfolio, fully expecting the rocket fuel to incinerate 90% of the portfolio, have 9% middling returns, and luck into that 1% home-run that was the actual rocket-ship hiding in plain sight. Sometimes, they can engineer M&A in this portfolio, to consolidate holdings and market share, hoping to profit from "winner takes all", even if the software org is 10x the size that it could be had it grown as a normal business, with similar % returns on investment.
🤕 re-upping this submit following the global #AWS outage. #HugOps to the people there, and everywhere restoring service.
Complexity is what it is...
However, I feel we as software people---executive, product, design, engineering, the whole nine yards---ought to think systematically in terms of Software Debt, as software organisations.
No more "technical" debt, as in "bad code" debt.
One thing I rarely hear discussed is why people take on "software debt". There are bad and good reasons to take on debt. Credit card debt is usually bad because of aggressive repayment terms, high interest rates, and ease of use (making it convenient for frivolous purchases). Home loan debt, on the hand, can be very good. The terms are highly favorable to the recipient, the interest rates are relatively low, and the underlying asset tends to appreciate. Not to mention you can live in it, have a family and self-actualize in a number of ways.
"Software debt", similarly, can also be good. Software doesn't live in a vacuum, it exists in the real world with things like people (and their skillsets), deadlines (both hard and soft), and money (which is finite in small organizations).
It's a dream for software engineers to live in a world of only 1s and 0s (and trust me, I've wished for that dream many times), but it's just not realistic. Sometimes we need to take on software debt to self-actualize and realize higher prospects with the things we do.
I take on software debt most frequently with personal projects, in fact. Why? Because there are no people skills to worry about (just my own), no non-negotiable deadlines, and unlimited/zero money (it's just whatever I want to spend of my own money and time).
I take on software debt to learn something new, or try an unusual pattern out, or just to get a proof-of-concept out the door in 30 minutes. Other times, I'm in a good flow state and don't want to carefully architect a side-concern of a subsystem while I'm on the way to something else. I keep a mental note of the "debt", usually with a TODO comment, and move on.
Finally, I can declare "bankruptcy" and walk away from any personal projects without repercussions.