Technical debt must be one of the most-used terms in technology. Every place I’ve worked has discussed technical debt and had a general belief that it had a lot of tech debt and that having a lot was a big problem.
I’ve never met or heard of anyone who said they had a different experience, like working at a company where all the code and systems were well-designed and up-to-date and thus “tech debt” never came up. Tech debt always seems to come up.
I also read a lot of technology books12 and the term “tech debt” is used freely and mostly without explanation. Everyone seems to assume everyone else knows what it means.
Reading Douglas Hofstadter3 has convinced me that metaphors are pretty much what thinking is, so it’s important to take metaphors seriously. I’m going to spend a few posts taking “technical debt” seriously to see what it reveals about how we think about technology and systems.
The parts of the analogy
I take the concept of debt to have three essential parts:
Something that is owed
Someone who owes it
Someone to whom it is owed
If we are using the analogy well, then we should have clear mappings for each of those elements to our particular situation. Let’s start with the Wikipedia definition of tech debt, derived from Ward Cunningham’s original formulation:
the implied cost of additional work in the future resulting from choosing an expedient solution over a more robust one
In future posts I plan to look at the definition more critically, but it’s a good starting point to take a stab at identifying how things map.
Sally has a choice to make
Let’s say Software Engineer Sally needs to add a new feature this sprint. And she’s got two choices, the Quick And Dirty Way that will comfortably fit into the sprint, and a Somehow Better Way, a way that will probably perform faster, or scale higher, or be more maintainable. The second way is just clearly superior to the first way, but it’s going to take a lot longer, and we really need this feature now.
So, duh, she picks the first way! Don’t judge, it’s not like you haven’t been there. According to the definition, this seems to be the canonical tech debt creation mechanism: a choice to put speed first, knowing that eventually we’ll have to do some rework down the line.
How does that map onto the analogy? Let’s get it started:
Clearly what is owed in this situation is the future rework, that’s core to the definition of technical debt. It seems like Sally is the one who owes it because she’s the only person in the scenario so far and she did make the choice after all. Let’s put her there for now. Sorry, Sally.
But to whom does Sally owe the rework? If debt really is the right analogy here, there has to be someone in the last box. Could it be … Sally?
This sort of makes sense, she might very well be the person who ends up doing the rework. But, also, really? Can you owe yourself ten dollars? How would paying yourself back work? If this is really what we mean by “tech debt” then I don’t think it’s a great use of the metaphor. It’s like saying you owe yourself more trips to the gym. Maybe you think you should go to the gym more, but calling it a “debt” to yourself doesn’t seem to add any explanatory power.
Perhaps it makes a little more sense like this:
Maybe it’s a future version of Sally to whom Sally is now indebted. An older, wiser Sally who will look back on her youthful folly, shaking her head sadly as she painstakingly refactors what her former self wrote, thus repaying the debt.
Maybe.
But.
I Still Don’t Like That Answer
Because Young Sally isn’t the one paying back the debt! It’s Future Sally who ends up paying it back to herself. If technical debt is a proper metaphor then all the parts should map appropriately and so far they just don’t.
I want to propose another way of thinking about the metaphor, a way I will continue refining in future posts. Here’s a start:
This mapping makes more sense to me because the person who owes and the person owed to are different people. That’s a real debt!
Another reason I think this is a better way to think about it is that when a professional submits work into a value stream, there’s an implicit expectation of fitness for purpose, a basic expectation of quality. Providing high-quality value is the essence of being a professional. When we choose expediency over quality, we know we aren’t entirely delivering on our remit. And that’s how the debt comes into being.
Putting the customer of the work in the last slot makes the metaphor map, but I also think it raises questions about the original definition of tech debt. I’m going to take those up in some future posts.
You can find me at https://app.thestorygraph.com/profile/dave_peticolas
Currently working my way through the IT Revolution back catalog. Go Portland Publishers!
I just noticed that Fluid Concepts and Creative Analogies was the first book sold by Amazon 😯