Let's not call it "tech debt," it's just "mess"
46 points by jdh
46 points by jdh
I disagree with this article’s definitions and assumptions of the meaning of the word “debt”.
Oh, you think entities taking on debt always understand what they’re getting themselves into? Individuals definitely don’t—in fact, lots of debts arise where no decision was consciously made. I don’t see any reason to expect businesses are much wiser.
Many get into debts that they cannot reasonably understand (subtly different from “which cannot reasonably be understood”, though that’s often true too) at the time the decision is made, and many debts have unexpected consequences down the line. So “tech debt” doesn’t feel an unreasonable label to me.
The problem with saying "technical debt" in these situations is it makes you look unserious. If you use "technical debt" to mean "a problem we didn't realize would be there when we made this decision" it makes you look like you take on debt without reading term sheets.
By this definition the world is chock full of unseriousness. Individuals take on debt without reading term sheets all the time, and I’ve seen enough of small business to know that it’s much the same, and I doubt it’s fundamentally better at medium and large business from the snippets I’ve seen from outside.
When I first read that line, I thought immediately of Luke 11:45–46. Jesus criticised the scribes and Pharisees for their hypocrisy, and one of the lawyers responded “hey, you just insulted us too!” clearly expecting an apology, but he rather said “yes, I meant to!”
Perhaps saying “technical debt” in these situations does make you look unserious—and perhaps you are.
There are useful distinctions between “this is a decision that will have foreseen consequences that we will address in the future” and “this is a decision that we have discovered unforeseen consequences of” and “this is a decision that we disagree with the past decision makers evaluation of the trade offs”. Using “technical debt” (or “mess”!) for all of these cases creates ambiguity when communicating with others.
These are all subsets of technical debt for which we do not (yet?) have concise terminology. Let's add another: "this is a decision that when it was made had foreseen consequences that the decision makers expected to address in the future, but they were never addressed, and perhaps forgotten entirely until they caused a problem."
There’s nothing special about tech debt here. We also lack distinct terms for credit card debt intentionally entered into versus credit card debt ignorantly entered into.
There are useful distinctions between those, yes. But I don’t think the article’s argument against calling it debt holds water—in the financial analogue, all three cases would still be called debt. You’d add an adjective if you wanted to be more specific, such as “intentional” or “ill-considered”, and if a category was common and important enough to warrant easy identification, you’d settle on a specific term.
For me it's simpler; technical debt is "we did X instead of Y because we thought Y would be more expensive short term."
What the author calls mess I would call a mess too, or a million different other synonyms.
This reminds me of the talk Technical Debt as Theory Building and Practice, which makes the case that home repair is a useful metaphor for thinking about and discussing technical debt. It's been a while since I watched it, so I may be misremembering some of it, but that aspect really stuck with me at least.
Housework, not home repair! It's a very good metaphor by Yvonne Z. Lam. I can't find/see her original thread [1], but I remember she wrote about the way both accumulate, and how “who will clean up” often comes down to “who cares the most”.
Thanks for linking to her talk, I will certainly watch it. For those who can't, here are the slides
[1] Maybe this thread? I can't see, I don't have a Bluesky account.
Technical debt simply doesn’t exist. Real debt has an interest rate, a principal balance, and terms—all finite, concrete things with measurable costs to maintain and pay off. Technical debt has none of them. Therefore, code cannot carry debt, only regret.
I grew up down the street from Ward Cunningham, the guy who coined the term “technical debt.” He’s a lovely and very smart fellow. I didn’t really absorb much about computing from him at the time. He and my dad mainly talked about PSK31. I mainly talked with his son about science fiction. I was still too much of a novice programmer to appreciate what a celebrity we had in our neighborhood. It was only much later as a software professional that I really appreciated his contributions (e.g. to Agile development and the wiki), and to respect and perhaps to an extent even idolize him. It’s with some trepidation that I criticize this term he coined. But, after two decades in industry, it never sat right with me, and not just because it’s often conflated with “mess.”
Those I’ve known who used “technical debt” most accurately did so to retroactively euphemize design decisions that, however cleanly they were implemented, later became obstacles to extending or maintaining a software project. I say “euphemize” because I have never known anyone to forecast future requirements perfectly and exceedingly few who understood the original requirements with 100% accuracy for anything much beyond a solo project. Therefore, to label code that no one predicted would later be regretted as an intentional act of an investor taking out a carefully calibrated loan is a tactic of conviction comparable to that of religious prophet.
Early on in my career, I when I found some code written by a senior dev that broke some maxim they taught me, they’d say, “I meant to do that. It’s technical debt. I took out a loan for us to pay off later.” It was nearly impossible to validate such claims—to distinguish between accidental debt and intentional debt. The scrupulous left comments in their code explaining what they anticipated might be surprising to its readers, but no one ever kept an exhaustive tally of all of this “debt” and no one seemed to know what would be required to pay it all off. The more maxims one learned, the more they contradicted each other: DRY versus the rule of three; premature optimization versus designing for performance; convention over configuration versus explicitness; do one thing well versus batteries included; self-documenting code versus literate code; fail fast versus the robustness principle; TDD versus BDD versus type-driven development and then back to TDD again with formal methods. It’s desirable for teams to consistently choose defaults from among these conflicting styles, but to cite them for the purpose of identifying debt has always smacked of hindsight to me.
Regrettable code is inherently paradoxical. A whole team of experienced professionals can agree that a piece of code is beautifully written one day and then come to regret it the next. Context is everything. It cannot be perfectly known, much less predicted. One can positively identify regrettable code in advance, but one can only negatively identify it (i.e. “we did not regret this code”) in retrospect; the only code anyone can say with certainty will never be regretted is the code that’s never run. Learning to write less regrettable code is more of an artistic practice than an economical one. It balances an intuition of the needs of humans—both for the present and in the near future—with a practical expertise in the tools used to build and run it.
What would you call the part between what you described "we thought it was ok, it turned out it wasn't" and "we just hacked it together"?
Because for me the most apt description is where you'd say "we can build the perfect solution in 2 weeks [but still can't predict the future, of course]" or accept this technically sound, but not optimal 2 day solution?
I mean, surely it's a tradeoff and the word is not wrong, but it's a tradeoff scoped to "this has a good chance that it will bring us problems in (usually) months, but it's quicker now".
Maybe it's just wishful thinking, but it's how I separate "just make it work somehow" versus "we thought about it and decided for the non-optimal solution", aka what I usually call technical debt.
But in the end I'm not even sure it's worth arguing, I think at work we classify a lot of needed refactoring or bugs that aren't really bugs, or non-focus improvements as technical debt, just to differentiate from a product roadmap - and I can live with that. (not really applicable to this discussion, I just wanted to mention it that I don't generally hold a strong opinion here)
Technical debt simply doesn’t exist. Real debt has an interest rate, a principal balance, and terms—all finite, concrete things with measurable costs to maintain and pay off. Technical debt has none of them.
Is software engineering engineering?
(Ah, shades of ENG1061 Engineering Profession, mandatory at that time for the Bachelor of Software Engineering because of misguided Engineers Australia accreditation stuff that I believe not one of the students in the degree cared about. The first lecture listed The Seventeen Branches of Engineering, which lacked software engineering; and it went downhill from there.)
Other times people say "debt" to mean "this isn't to my taste." I've known teams that decided their proliferation of container images was "technical debt" and spent a few weeks consolidating them into one image. Then a year later and with some new personnel on the team, they decided that having a single container image for everything was "debt" and broke it up into a bunch of focused images.
I'm not against aesthetic judgements. They're underrated in our field. I don't even think either version of that team necessarily did the wrong thing. But "this work is organized in a certain way that has tradeoffs I don't like," isn't "debt."
I've seen this sort of advocacy for, essentially, pet projects at a lot of companies over the years and I do think it's made me skeptical any time I hear the phrase "tech debt" now.
Well yes, that's what many of us always thought of it. But business does like it. The whole "agile" methodology has its merit for putting frequent customer input in the center. But other than that, it is essentially a culture created to accommodate lack of skill and competence.
You wouldn't need agile if projects were mostly delivered on time and properly planned/spec'ed. Of course management and business likes it too. Speculative markets go by company growth, often measured by how many employees a company has, or its budget.
Does business really like it? I would think they would like it in the sense of asking for more of it (I can get things done more quickly with "debt" not showing up on the balance sheet? awesome - is there also technical stock - can we do a technical IPO?)
Business asks for more of it all the time. A new greenfield project. A new team, more engineers to a given team. Management lives for this. Try make things simpler and smaller and more efficient than what they are and watch management response. Do you think they like it? They won't. It will question much of the status quo of the organization, you will be excumunicated in no time.