Almost 30 years ago at an Association for Computing Machinery conference in Vancouver, a programmer named Ward Cunningham changed software development — or at least its parlance.
Cunningham presented a report on a portfolio management system his then-employer Wyatt Software built for a client. In that report, he wrote: “Shipping first-time code is like going into debt.”
And the technical debt metaphor was, by all accounts, born.
Technical Debt, according to Cunningham
It wasn’t breaking news that there’s a person-hours cost to shipping code with the intention of fine-tuning it later. But debt was such a useful analogy for this problem, the term stuck.
Fast forward a few decades, and technical debt is still software engineering shorthand — but for what? And why? Efforts to quantify technical debt into dollar amounts have been scattershot, and discussing the concept can get developers heated — like in this comment thread.
One user wrote a 900-word response, starting with, “The very concept of tech debt, though prevalent, is pernicious, because it’s a concept that is far, far, far too fuzzy.”
A user below countered, “Lots of terms — really, every term — is fuzzy at some resolution and thus all understanding is inevitably fuzzy, too.”
Cunningham — who’s also credited with developing the first Wiki and co-authoring the Agile Manifesto — is aware of the contention. Seventeen years after coining the debt metaphor, he released this video clarifying his original thinking. The software development blogosphere had misunderstood him, he said, and mixed up technical debt with defective code.
[It’s been confused] with the idea that you can write code poorly with the intention of doing a good job later.”
“A lot of bloggers have explained the debt metaphor and confused it with the idea that you can write code poorly with the intention of doing a good job later,” he said. “I’m never in favor of writing code poorly.”
The mix-ups don’t end there, though. Technical debt has come to mean different things to different shops — and only some of those definitions are helpful. Three decades after its minting, is the term “technical debt” still worth our while?
Today, Technical Debt Means Almost Everything...
In a piece for entrepreneurship publication The Startup, 4Degrees co-founder and CTO David Vandegrift argued that technical debt isn’t real.
It’s not a popular opinion. In fact, Vandegrift warned me it could “trigger people.”
Vandegrift’s take may be unique, but it’s not far-fetched. The two-time founder and technology chief thinks technical debt has become, in a word, “bullshit.” Not because the original definition was off point, he said, but because that definition no longer gets much play. Instead, technical debt has come to refer to anything developers don’t really want to talk about.
Cunningham attributed this confusion about technical debt’s definition to tech bloggers, but Vandegrift sees real-world misapplications all the time. About 60 percent of the time, he said, it’s developers mislabeling shoddy work as technical debt. Twenty or 30 percent of the time, it’s managers masquerading their own stylistic preferences as concern for technical debt. That doesn’t leave much room for Cunningham’s version of technical debt — when engineers spin up an incomplete solution to iterate and improve.
“If you look at scrum agile, a lot of it recommends having specific time set aside for technical debt, which is a great way to actually quantify the cost this is having to organizations if you assume or realize [technical debt] isn’t a real thing at all,” he said. “If an organization has identified 20 percent of every sprint is dedicated to technical debt — which is not an unusual number — it’s like, oh, cool, you’re spending 20 percent of your time doing stuff that adds no value.”
[You don’t discuss] what is actually being addressed when the person’s working on technical debt.”
In other words, time dedicated to paying back so-called technical debt may be more about assuaging manufactured anxiety than solving actual problems in the architecture or codebase. Why, Vandegrift asked, spend time fixing issues the end user would never notice or care about?
Today, technical debt has become an umbrella term, he said. Don’t want to tell your new hire their code is bad? Tell them it would accrue too much technical debt. Want to sidestep stuffy protocols and push some code into production? Tell higher-ups you’re taking on some technical debt. Want to spend a full day each week circling back on code you shortchanged the first time? You guessed it.
“It’s a big obfuscator, and it’s one of these things that’s become hard to argue with,” Vandegrift said. “If you say, ‘Hey, we have technical debt, we need to fix it.’ You almost have this straw man where if someone argues against doing that, they must think technical debt is good. It becomes this untouchable concept in the organization, so you don’t end up with a super in-depth evaluation of what is actually being addressed when the person’s working on technical debt.”
...Except for Actual, Monetary Debt
If Vandegrift is correct, the problem with the technical debt metaphor could be that it’s become imprecise; if we use a term for everything, it starts to mean nothing.
But technical debt might stir up programmers’ ire for the entirely opposite reason: The metaphor has been interpreted too rigidly.
Philippe Kruchten, a software engineering professor at the University of British Columbia and developer of the 4+1 architectural view model, has written extensively on technical debt. Kruchten said the technical debt metaphor is highly useful when it’s not referring to plain old defective code. For example, when companies are rushing to show an MVP to venture investors, or reckoning with past decisions about languages and frameworks, technical debt is an essential conversation, he said. (He sent over this list of practical ways to manage technical debt.)
If you never have to touch that code again — because it’s a badly designed program but it works — the analogy would break.”
However, the financial metaphor doesn’t extend very far.
“A lot of people take the metaphor literally and say it’s like a mortgage, but it’s not exactly like a mortgage,” Kruchten said. “You only have to repay technical debt if it prevents you going forward. So, you could accumulate a lot of technical debt. If you never have to touch that code again — because it’s a badly designed program but it works — the analogy would break.”
Technical Debt, according to Kruchten
Really, finance in general might be a shaky way to describe software engineering decisions. People have tried to create models that assign a dollar value to technical debt — if it’s debt, we should be able to quantify it, the thinking goes.
Those efforts, Kruchten said, haven’t produced useful results. Beyond some basic intuitions about the real costs of technical debt — like that architectural debt is more costly than code-level debt — measuring technical debt in dollars is an example of how technologists try to “make the analogy much too close,” he said.
But the mismatch between the financial world and the world of software doesn’t stop people from trying. Check out the list of accepted papers at TechDebt 2019, an international conference on technical debt: One is literally titled “TETRA, as a Set of Techniques for Calculating Technical Debt Principal and Interest.”
Meanwhile, these programmers suggested that technical debt would be more accurately described as a “naked call option,” finance terminology for when an investor sells call options without owning the underlying security.
That blog sparked debate on Reddit and Hacker News. The first comment on the thread?
“Technical debt is actually a really good analogy, precisely because non-technical finance people understand the tradeoff pretty intuitively.”
With all this grasping for money metaphors, you’d think software engineers spent decades beholden to finance people with little understanding of the work they do. (They did.)
Talking to People Who Don’t Code
From the start, technical debt has been a communication tool. Cunningham used the metaphor to help his boss understand why the team was circling back to refactor code. In Kruchten’s consulting work, he uses the term largely for interdepartmental discussions.
“The more people have a clue what software development entails,” he said, “The richer the discussion will be.”
The usefulness of the technical debt metaphor for non-technical bosses and coworkers could explain some of the bad behavior surrounding the term, Vandegrift said. Developers don’t want their decisions critiqued by people who don’t understand them.
But coding isn’t that mysterious, according to Vandegrift.
“It’s certainly understandable, even by businesspeople,” he said. “However, the vast majority of businesspeople don’t understand it. So I think there is legitimate concern there, particularly on an organization-by-organization basis. If you imagine you’re an incredibly talented engineer at an organization that doesn’t understand and respect engineering, it’s easy to see why your incentive would be to hide the work that you’re doing to the extent you can.”
Time Is Money. In Fact, Everything Is Money.
Technical debt gets misinterpreted and misused. It’s an imperfect metaphor. But developers hang onto it because it’s useful in corporate environments.
Or maybe that’s not why they hang onto it at all.
Using finance to talk about non-financial things isn’t limited to engineering shops. We humans use money as metaphor all the time. In Stephen Covey’s bestselling 7 Habits of Highly Effective People, for instance, he encourages readers to keep close tabs on their “emotional bank accounts” — and to be thoughtful as they “deposit” and “withdraw” from others.
If a person does something wrong, he could be ethically “bankrupt.” If a company does something embarrassing, it will say the mistake goes against its “values.” If a friend does me a favor, I’m in debt.
Ultimately, it’s about the emotions involved.”
Money helps us explain how we feel, and the same is true for developers. Shipping an incomplete solution or rewriting existing code feels kind of bad — and so does financial debt. Voila: a runaway metaphor.
Does that mean the disputes around technical debt could be solved with a simple shift of perspective?
Squarespace engineering manager Jon Thornton thinks so. He subscribes to Kent Beck’s preferred term — technical investment. It’s still a financial metaphor, but the positive spin makes it feel more like a strategy and less like a problem.
“I think there are a lot of situations where an engineer is asked to cut meaningful corners to hit some delivery goal,” Thornton said. “That’s stressful, and it builds an emotional connection between the term technical debt and that bad feeling that you’re doing things the wrong way. Ultimately, it’s about the emotions involved.”
Strategic technical debt can springboard organizations to new levels of success, Thornton argues here. Spinning up and testing risky code components, hardcoding small features and intentionally ignoring funky edge cases are all good uses of technical debt, he said, as long as those decisions are made with purpose.
All in all, it’s tough to argue that technical debt isn’t real. Inefficient or outdated technologies can bring companies to their knees — Kruchten thought of an old example in Baan, a Dutch firm that built its product on IBM’s AS/400 operating system using the language RPG. In the time it took them to convert to Java, outside competition — and manipulative financial reporting — forced the company to sell.
Maybe a better question is: Is the term “technical debt” helping?
That depends on who’s wielding it. If the debt metaphor has become a convenient way to bypass bosses, coddle unskilled developers or make nice with corporate types, it’s likely not serving you. And if it’s a maniacal hunt for the perfect computer-science-cost-crunching financial comparison, give up now.
But if you’re referring to the well-designed, partial solution or the aging framework or the inconveniently named variable — sure. Those problems significantly slow down developers or affect end users. They need to be fixed, and fixing them requires person-hours, and those person hours are an investment in the future.
