Why Technical Debt is a Hard Sell
The psychology of tech debt and common misconceptions
In the world of software development, we often find ourselves juggling between delivering features quickly and maintaining a clean, manageable codebase. This balance, or often the lack of it, gives rise to what’s commonly termed as “Technical Debt”. Much like financial debt, technical debt accumulates when you opt for a quicker, suboptimal solution now, with the intent to address its consequences in the future. It can also be the result of not keeping up with change, or by simply becoming obsolete.
While many developers often stress the importance of technical debt, it’s often dismissed by management. But why is addressing technical debt such a hard sell? We all know tech debt is bad, right? Are tech managers evil or incompetent?
The disasterous effects of technical debt are well documented. Take for example, the notorious healthcare.gov website for the U.S. Affordable Care Act. When it was launched in 2013, it faced significant issues due to it being buggy, inefficient, and hard to maintain, which led to its collapse upon launch. It was so bad that it became a huge political issue for the Obama administration, with the President himself trashing the website.
No, I don’t think most managers are stupid. I think there is a more practical explanation:
One reason why many don’t prioritize technical debt is that they simply don’t see the benefit when compared to other priorities. After all, it’s commonly understood that technical debt, similar to financial debt, can be paid back later. Even if it comes with added costs down the road, many theorize this cost will be worth paying once that big contract is landed, or that shiny new feature goes out.
And to an extent, they’re right. Technical Debt, similar to a loan, is a way to borrow from the future. It can indeed be a viable strategy for small rapid prototypes, or to hit a short deadline for small changes. As long as the code is re-written shortly after, we can call this debt “managed”.
A major caveat, however, is that this only works for tight-scoped projects where reliability or scaling isn’t a major concern.
Unfortunately, it seems many people don’t really understand the true nature of tech debt and its cost. Perhaps it’s because the financial metaphor only goes so far. After all, it’s just a metaphor — not a definition.
Technical debt has an optics problem
Many people believe having technical debt simply means added costs at a later date. However, that’s only a tiny part of it. Unfortunately, this common definition and the whole financial analogy are incredibly misleading.
At its core, technical debt is when it’s hard to change things. This can be due to outdated dependencies, vendor lock-in, absence of automated tests, lack of documentation, confusing code, outdated abstractions, tight coupling, or other deficiencies. Often, code with technical debt is hard to change because it’s hard to understand. Maybe it was actually good code once, but time has moved on, and the code hasn’t.
The real cost of technical debt
When Ward Cunningham coined the phrase in 1992, he noted that these “borrowings” manifest as “interest” not just for future costs, but more importantly, increased development times and decreased programmer productivity. For whatever reason, only that first part seemed to stick.
However, it’s actually so much worse. Unmanaged tech debt is the kiss of death for reliability, security, scalability, opportunity, and planning.
Poor reliability
A system bogged down with technical debt is exponentially more prone to bugs and crashes. This is due primarily to confusion resulting in a lack of understanding of the code and larger system.
A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. — John Carmack
Software is basically a million-part Rube Goldberg machine, where it crashes if any one thing goes wrong. Why make it harder when you aren’t even sure how most of it works?
The tight deadlines and cumbersome development process these teams face also play a key role. Finding, understanding, and fixing these bugs can take a lot of time. And when things are already barely getting done on time, attention to detail and testing are often sacrificed, resulting in even more tech debt, which creates even more bugs. This is a vicious cycle that quickly results in an unrecoverable software black hole.
Opportunity cost
Every moment spent navigating the maze of a debt-laden codebase is time not spent on creating new features, innovating, or improving the system. This slows down the pace at which a team can deliver, causing missed opportunities for the business. For startups, this can be deadly.
Security concerns
Outdated dependencies or convoluted code can lead to vulnerabilities. With ever-increasing cyber threats, a system burdened with technical debt often becomes a low-hanging fruit for malicious actors. This can also result in major financial liability.
Equifax’s 2017 data breach, affecting 147 million people and resulting in a $575 million fine, was largely due to its reliance on unsupported, obsolete technology.
Here’s an excerpt from the complaint filed by the FCC:
ACIS [the affected software]… runs on old systems, many of which are no longer supported. Today, Defendant considers ACIS to be legacy infrastructure and its own documents describe the system as “archaic” and using “antiquated technology.”
Unpredictability
Technical debt introduces uncertainty. Estimations become unreliable because engineers can’t predict the complexities they might uncover as they wade through the code. With a complex, debt-ridden codebase, every change becomes a potential landmine. The risk of introducing new bugs increases, making deployments a nail-biting event. Forget about your 12-month roadmap — you can’t plan for next week.
High development costs
Try putting together a 1000-piece jigsaw puzzle with some pieces missing, some the wrong shape, and the wrong picture on the box. That’s what it’s like working on a codebase with unmanaged tech debt.
The real cost isn’t just in the expensive refactoring tasks that loom in the future, it’s in the daily grind — the little inefficiencies developers face every single day, the workarounds, and the “this is how we’ve always done it” explanations. It’s the avoidable errors that compound over time. It’s the hours wasted chasing down preventable bugs, putting out fires, and the inevitable burnout and turnover.
Scalability concerns
Technical debt severely hampers scalability. Whether it’s scaling up the features, handling more user load, or even growing the team, tech debt makes it all daunting. Just look at the aforementioned healthcare.gov fiasco.
New hires face a steep learning curve, making onboarding inefficient. Deploying code might be an arduous, time-consuming task. The system itself may falter under load or become too rigid to adapt to new requirements.
Programming is learning
While a comprehensive guide to avoiding technical debt extends beyond the scope of this piece, there are a couple of simple things you can do right now, starting with the way you see and approach tech debt as a team.
One consideration is to restrict any debt “loans” to a single short development cycle. It’s crucial that any shortcuts or quick fixes introduced during this phase are promptly addressed afterward. Again, may not work with mission-critical or highly scaled systems.
More importantly, continuous code cleanup must be woven into the daily work of every software development team. Programming isn’t just about writing code — it’s a perpetual journey of learning and adapting. As teams deepen their understanding of the problem domain and encounter evolving requirements, the code needs to evolve accordingly. A conscious effort to perpetually refine, simplify, and clarify the code ensures it remains robust and adaptable, mirroring the knowledge of the team.
TL;DR
Technical debt isn’t just a developer’s concern — it’s a business concern — and a major one.
According to a 2020 report from the Consortium for IT Software Quality (CISQ), the cost of poor software quality in the U.S. alone has ballooned to over $2 trillion every year. Much of this is a direct result of unmanaged technical debt.
Technical debt is a massive liability for your business, especially if your business is reliant on custom in-house or outsourced software.
It’s not merely about messy code or outdated libraries; it’s about the gradual erosion of reliability, security, agility, efficiency, and innovation. It’s a silent killer, often overshadowed by immediate business goals.
An engineering culture that values sustainable efficiency will simply be more productive over time than one that doesn’t. It’s also much less risky. Prioritizing continuous code refinement and clarity as a part of every sprint is a great start.
Organizations that fail to understand technical debt, refuse to take it seriously, or relegate it to something “only nerds care about,” are actively working against themselves. They might as well go punch themselves in the face.
Want to read more techniques for writing reliable software at scale with maximum developer efficiency? Follow me on Medium and read the article below:
