Technical Credit Scores
Code Fico? Equicodefaxunion? How I think about the scourge that is Technical Debt.
Why does a company or person take on debt? It's usually to make something happen that they would otherwise be unable to achieve in return for a bit of interest and management of the debt.1
Over time a company might issue a bond, or take a line of credit, to buy a machine so they can expand operations. Perhaps they took on debt to be able serve a customer contract they'd heretofore been unable to serve, or were only able to do so less efficiently.
Maybe they took money when it was cheap to do so and converted expensive money to 'cheaper' money, boosting the returns on the work that they enabled with the debt.
While you can tell I’m not an economist, I have been involved in engineering management for most of my career and when I hear my colleagues in the industry complain about technical debt I have a familiar reaction. Churlishly, I want to say “Oooh, look at the person with all the customers” but I usually try to act my age and ask what outcomes did that debt make possible?
That pile of spaghetti code that you're not particularly proud of, or are spending 10% of your time maintaining, how much revenue does that represent? Which users made the creation and maintenance of that code practical? Why all the heartache if there’s no upside?
When I was at a former employer we had an application that was, to put it mildly, disliked. The codebase I’m thinking of was pinned to a previous, inefficient, ugly UI framework, used bits of android that no one really liked to use anymore, had a backend storage system that was older than most android users, and it had a miniscule and yet still declining user base.
People on the team couldn't fathom why we were maintaining it (and the code underpinning it) for so long. For years it was a wart, a barnacle, a carbuncle2, on the side of a team maintaining an otherwise decent collection of programs for a platform that we shipped.
I remember when it came to a head and they begged the powers that be to kill it. To burn it with fire. The person in charge said, 'No way' and when they asked why, he said "The CEO of our most important partner uses it." So while to them it represented debt, and toil, and pain. To the people in charge it represented keeping a nearly billion dollar channel happy.
I'd love to tell you the team, newly inspired, fixed, modernized and improved the app and their lives maintaining it, but I wouldn't want to lie to you, dear reader. In that case, they tread water until the lead user exited the partner, then they killed it off. They probably had a party to celebrate, with hats, banners, crackers and those horns that people honk when there’s a party in the movies.
What's the interest rate on your technical debt?
In the example above, the benefits from the technical debt was measured in literal millions and priceless goodwill. The credit score for that debt was quite high.
Where I'm going with all this is when you see a pile of code , think not of the pain it causes, think instead of how it's valued. If the value is high enough, address the debt by making it cheaper to maintain. Like refinancing a home loan to save 2% or 4% on a loan. Consider refactoring, updating or re-implementing your technical debt in reaction to its value. This is something I encourage project teams and programmers to do. Valuing the code you write and maintain is always something that should be done against the cost of updating and maintenance3 .
There's a tendency in our industry to, well, declare bankruptcy in the face of technical debt. I can even think of multiple instances where this was the absolutely right decision. Shutting down a service or product line, handled correctly, can even improve your relationship with your users for new initiatives you might find yourself leading or releasing from the company. 4
Shutting down a project that is clearly doomed is often a kindness for talented engineers, you can enlist them in better, more relevant projects and they can come out of it feeling like their time is valued. No point wasting a minute more than necessary on doomed work.
I sort of think of this in mathematical or chemical terms: People focus on the debt, but you have to calculate it alongside the asset value. The debt by itself is an incomplete, unbalanced, equation. It’s like retreating in horror from table salt because you only see the Cl part of NaCl.
Obviously I’m not talking about folks who take on debt to buy door dash, or to pay off losses with their local fan duel … I don’t even know if fan-duel has local enforcers. Despite my simple upbringing as a Sicilian boy born to a math teacher and a physicist in Las Vegas, I never fell sway to the entwined sirens of gambling or loan sharking…
Listen, don’t look up the word carbuncle. Just don’t. In fact go back to the essay before I describe it thusly: Think of it as if a wart and a barnacle had a baby on your hand. It’s, like, super gross.
I think banker types call this benchmarking, but if I start talking about benchmarks I’ll start going on about lmbench or some other testing harness and this essay will go further off the rails than when I footnoted about carbuncles.
And no, dear readers who are looking for reader references, this is not that. Reader was shut down without regard for the importance of its user base for reasons that had *nothing* to do with technical debt. I and many many many other people tried to save it to no avail.