Tech debt is inevitable. People know this and address it when they can, but most of the time they just know it's there, lurking in the corner and growing. 

When talking with a business owner or product lead about technical debt, a single statement is impactful: 

"If we don't spend the time getting this simple part done, there will be a hole in the software." 

People intuitively understand that a hole in something is usually bad and needs fixing. 

The term "tech debt," on the other hand, sometimes sounds like something you can throw money at to make it go away, but it is never that simple.

Tech debt, or holes in software, can arise in several ways, and understanding where it comes from (the software's structure, the people around it, and the process of writing and committing code) builds foresight. 

Broken maps

Software structure is the set of large components that create its overall abstract shape. Think of the language, framework, database, and servers used to build a web application. You can get more specific, but each choice of component, and how the components connect, matters. Each component has properties that work well for some things and poorly for others. 

Structural tech debt mostly comes from components that don't suit the business need. For example, for an IoT device like a smart thermometer, you may want SQLite because its low memory cost allows on-device storage. PostgreSQL would use far more memory on the device, but offer more complex data capabilities. 

If the thermometer doesn't need those capabilities, SQLite makes the most sense. You want to make the right decisions, but real life is far more convoluted, and it's impossible to get these decisions perfect, especially under real-world pressure and with the changing nature of software.

Structural tech debt can be brutal because once you're in a hole, it's hard to stop digging. 

For many reasons, like talent limitations, deadlines, budgets, and time, structural debt really shows up when the decision is made to build on top of structural issues rather than fix them, and it’s the default decision more often than not.

For example, say a three-story building was designed with stairs instead of an elevator, for cost and needs. Later it became profitable to add two more floors, so the stairs were extended two more flights. This kept happening, and it kept making sense to add more stairs with each new floor. 

Over time, we end up with a fifteen-story building that has only stairs. It does the job of a building with an elevator, but at a far greater physical cost to its residents. Installing an elevator now makes sense, but it means contending with fifteen stories of stairs. 

That's how structural tech debt accumulates. Developers can get very good at making pieces of architecture do things they were not intended to do, and it takes a great deal of resources to patch that hole.

The call is coming from inside the house

So if tech debt can come from the structure of the program, where else can it present itself?

In you.

We’re mostly joking. 

Tech debt accumulates from what people do and don't do. Different teams tackle testing, code review, and code conventions to varying degrees, but discipline is essential to implementing any of them meaningfully. 

A lack of discipline in testing means bugs accumulate unnoticed, and a false sense of confidence encourages the team to march forward without proper provisions. 

A lack of discipline in code review means leads get sloppy and let in code they don't understand. Over time, the team develops a less accurate picture of what the software actually is, creating a hole in the team's knowledge. 

Coding conventions are more of a larger-codebase or company-wide effort. Ignoring them creates an inconsistent codebase where developers constantly recontextualize or learn different ways to read the same thing. This creates friction between developers and ultimately a need for refactoring when the codebase feels like mud to traverse.

The local tour guide is worth the money

Tech debt also comes from turnover. Project and company knowledge lives overwhelmingly in employees' heads, interactions, and environments. When people leave the company or project, their map of the tech debt leaves with them, and the debt can grow unchecked. 

High turnover also means continuous contributions from team members who, by nature of their tenure, have a limited understanding of the project as a whole. This produces localized solutions rather than reusable, comprehensive approaches. Code written without the full picture is tech debt.

A fundamental consideration

Lastly, let’s look at some newer forms of tech debt. The development process, especially code contribution, has changed greatly with the integration of LLMs. 

Lead developers now review far more code than before, since they review not only what developers write but what their LLMs produce too. This is currently a big leak in the development process, and it's worth knowing that leads can only review so much code before their sharpness wanes and the quality bar drops.

Code generated by LLMs is more likely to become tech debt than code written by people. This stems from how LLMs work.

One of the best contributions a developer can make is removing code without impacting functionality. LLMs are generative: first and foremost, they add. LLMs have even been shown to create new optional paths rather than delete code. A tool that is more likely to add than to simplify is more likely to complicate or obfuscate, and so more likely to create tech debt. 

LLM-generated code is often more verbose than it needs to be, and it's not efficient to focus on making code less verbose. That isn’t to say LLMs only cause tech debt, but each time we accept that tradeoff, we let in more noise. 

Know where to look

Tech debt is inevitable, and it shouldn't surprise us. It can come from a project's big abstract structure, from people, and from new places as technology evolves. 

Software is infrastructure, and infrastructure needs maintenance.