Metaphor for bad debt
Technical debt – good or bad?
This morning, Chet and I were debating technical debt. This item from Ward Cunningham, the term’s author, served as a starting point for our discussion. To begin the discussion, Chet said that he believes the word “technical debt,” as it is currently used, is too mild to adequately characterize some pretty bad conduct. I even went so far as to say that Ward’s initial coining of the word was maybe a little too gentle.
Our main concern is that debt is something that can be wisely entered into: we borrow money to go to college, purchase a car, or buy a home. We will get the value as if we had the money all along in exchange for paying some interest. Depending on the interest rate, one’s willingness to pay, and other factors, this could be a perfectly reasonable decision.
We’ve all heard stories of people who made poor financial decisions. I had credit card debt that was around one-third of my annual income before taxes at one point in my life. That was a terrible idea, and it took me some time to straighten it out. Even cleaning it up was costly: I think I sold some stock before its expiration date. Payday loans, as common as they are, are almost always a bad idea because the interest rates are too high. And so forth. There are several ways to incur debt in an unwise manner.
Git workflow strategies for technical debt management by
Is it, however, effective? Is this analogy accurate in describing the need for refactoring? Are we able to effectively transmit the message? Do we achieve our aim of finding time to refactor by discussing technological debt? And if not, what’s the hold-up?
Ward Cunningham coined the phrase when he compared shipping code faster by doing things we know aren’t quite right to taking on debt. He used this idea to illustrate the importance of software refactoring to his boss, who worked in finance.
“I thought rushing tech out the door to gain experience with it was a good idea,” he said. But, of course, when you learn more about the app, you’ll be able to repay the loan by refactoring the program to represent your newfound knowledge.”
The word has been diluted since then. Technical debt has been blamed for almost everything, from smelly code to incomplete documents to the process of recruiting people with the wrong skill set.
This overuse of the metaphor isn’t beneficial because it makes it more difficult to understand. When we try to describe it, it almost seems to slip through our fingertips. Technical debt may be anything and anything. So, what’s the best way to describe it?
What is an extended metaphor? lesson and activity
Steve Freeman wrote a blog post in 2010 titled “Poor code isn’t technological debt; it’s an unhedged call choice.” He clarified how Chris Matts came up with the concept of using an unhedged call alternative as a metaphor for bad code:
For cruddy code (without tests), call options are a better model than debt because they capture the unpredictability of what we do. I get the value right away if I slap in a feature without cleaning it up, and I earn the premium. I’m ahead if I never see the code again, and it would have been stupid to waste time cleaning it up in retrospect.
In the other hand, if a major new function is introduced that I must implement, all of those fast fixes become prohibitively costly to implement. A large new client that involves a port to a different network, or a new regulatory requirement that necessitates a new report are two examples I’ve seen. When I have to interpret and repair a mistake right before a deadline, or when team members quit and no one remembers the tacit information that makes the code make sense, I have similar issues. My choice has been named because the market has shifted away from where I expected it to be.
Sovereign debt (national, government or public debt
How can we talk about nightmares if software is the stuff that dreams are made of? We use metaphor to interact and reason about software because it isn’t the tangible, kickable stuff that our senses are tuned to.
Spaghetti code was coined in the 1970s to explain the tangle of unstructured control flow. This has spawned a slew of software-as-pasta metaphors, ranging from lasagne for layered systems to ravioli for objects, components, modules, services, and microservices (to name a few). Spaghetti, on the other hand, has nothing to give us as a metaphor beyond its disorganized arrangement. It doesn’t give us a useful mental model for discussing code, and it has far too many positive associations. It’s not clear that one of these is worse for your software infrastructure than the other if you like both ravioli and spaghetti.
A metaphor is a mapping that we use to explain one thing in terms of another, sometimes to show something familiar from a new perspective, as in poetry, and sometimes to show something unfamiliar or abstract in a more familiar light, as in software. A metaphor must have a number of points of useful correspondence with the thing being represented in order to be considered successful. Pasta isn’t quite up to the challenge.