Let’s talk 𝘁𝗲𝗰𝗵𝗻𝗶𝗰𝗮𝗹 𝗱𝗲𝗯𝘁. That dreaded phrase engineering uses right before product roadmaps burn, deadlines vanish, and customer commitments go up in smoke. Much like a “𝘥𝘳𝘢𝘤𝘢𝘳𝘺𝘴” during planning and status meetings, it signals impending doom.

But it doesn’t have to be this way. Technical debt is often misunderstood by non-engineering stakeholders, leading to decisions that harm product development. Engineering leaders sometimes overreact, proposing drastic rewrites or enforcing a strict zero-debt policy that slows all development down to a crawl.

So let’s start by getting clear on the basics.

What is technical debt?
Technical debt is the implied future cost of making changes to a codebase or its parts. This cost can manifest as increased development time, reduced performance, scalability or stability, and a greater potential for introducing bugs.

How does it get created or added?
Technical debt is added when a change results in a less maintainable codebase due to increased time, complexity and risk of making future changes, than it would have been without the change.

How is it removed or reduced?
Technical debt is reduced when a change results in a more maintainable codebase due to decreased time, complexity and risk of making future changes, than it would have been without the change. This is typically achieved by refactoring, modularizing, enhancing test coverage, and updating documentation.

Let’s look at a real world example.

Bob needs to modify unfamiliar, messy code. He initially underestimates the task, thinking it should be simple. When he starts, it takes several days just to minimally integrate his changes without breaking anything. The messy code forces him to write even more messy code to get everything to work. As expected, this leads to insidious production bugs that take weeks to fully resolve.

As a result of Bob’s changes, the next person to work on that codebase will find it even harder to make changes, potentially leading to more bugs. Bob has just added technical debt.

Alice, a senior engineer, later needs to modify the same code. Horrified by its state, she convinces her manager and product manager to let her fix it. She improves the code’s structure, adding tests, and documentation.

As a result of Alice’s changes, everyone who works on that code in the future can do so faster and without introducing hard-to-find bugs. Alice has now reduced technical debt.

Not all technical debt is bad. There is avoidable technical debt that can be minimized with simple mechanisms. Technical debt can also be used as leverage, such as taking a calculated shortcut to quickly prototype a feature for user feedback, speeding up product development.

Team that judiciously uses technical debt will always out-perform teams that ignore or completely avoid technical debt.

In a follow-up post, I’ll share tips on how to avoid creating unnecessary technical debt and ways to use technical debt as leverage.