The common understanding is that (tech) debt is something bad. That creating tech debt should be last resort. And that’s how we use that metaphor. But if you go back to the root of it, and remind yourself what debt actually is, it turns out it doesn’t intrinsically have to be detrimental. In fact, tech debt has more to do with PDSA than with spaghetti code, and was initially coined as a name for a good practice. Moreover, it was invented as a way to convince execs to allow an earlier release, which feels bonkers contrasted with our contemporary way of talking about it. So let’s overthink it…
Is debt always bad? Well, my apartment is a result of debt. So is my car and the laptop I’m writing this on. But it’s not like I can’t afford these things, I just can’t afford them immediately. If I wanted to buy them without debt, I would’ve had to save money over time. Debt allows me to tap into the future so I can use the stuff I’m saving for. Neat. Of course it comes with a “spacetime warping tax”, called interest, but as long as I can afford it all it’s a great deal.
There’s one important thing to remember here, though. It only works this way if the stuff you acquire with debt has the potential of making you money, directly or indirectly. So it works with a faster laptop for a programmer, but not with a huge TV to watch Jersey Shore. To drive this point home, the common understanding of tech debt is that of a payday loan — something that cripples you with insane interest for no good reason. To quote Fight Club:
We buy things we don't need with money we don't have to impress people we don't like.
— Tyler Durden
But that’s not the idea Ward Cunningham had in mind when he coined the term. His thinking was that of an investment loan. A smart, calculated decision which allows your business to grow. Something businesses do all the time. Explaining that he says, and this will be a long quote:
With borrowed money you can do something sooner than you might do otherwise, but until you pay back that money you’ll be paying interest. I thought that borrowing money was a good idea. I thought that rushing software out the door, to get some experience with it, was a good idea. But then of course you would eventually go back and, as you learned things about that software, you would repay that loan by refactoring the program to reflect your experience as you’ve earned it. (…)
A lot of bloggers, at least, have explained the debt metaphor and confused it with the idea that you could write code poorly with the intention of doing a good job later and thinking that was the primary source of debt. I’m never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem, even if that understanding is partial. (…) You’re wise to make that software reflect your understanding as best you can, so that when it comes time to refactor it’s clear what you were thinking when you wrote it.
(…) the ability to pay debt back depends on your ability to write code that is clean enough to be able to refactor.
— Ward Cunningham (source)
Let’s dissect it a bit more. What he says is this: try to understand the problem you’re solving, write good code to reflect that understanding in hope it will solve the problem, give it to your users, learn from their feedback, and improve the software based on what you've learned. Which is precisely what both Kinslow and Deming tell us to do. While Cunningham’s explanation is much more wordy, in essence it almost exactly follows the Kinslow quote I keep coming back to:
The design process is an iterative one. I will tell you one thing which can go wrong with it if you are not in the laboratory. In my terms design consists of:
1. Flowchart until you think you understand the problem.
2. Write code until you realize that you don’t.
3. Go back and re-do the flowchart.
4. Write some more code and iterate to what you feel is the correct solution”
— Holis A. Kinslow
The tech debt metaphor is just another reinvention of the learning from feedback idea underpinning PDSA. It has nothing to do with writing unstructured, poorly named spaghetti code. The debt metaphor is about making sure your debt is an investment. It buys you the feedback you need to improve your domain modeling and get ahead of competition.