What is Technical Debt?

At DNSimple, we think about technical debt a lot. Dealing with inherited debt and being smart about how we introduce new technical debt is just part of building a successful product. How we view, plan for, and manage that debt is critical to our software development process.

Every system that evolves over time accrues technical debt. Depending on the number of contributors to that system; the complexity, the rate of change, as well as other factors, that debt may accrue slower or faster from system to system.

So what is technical debt? And why does it matter to anyone outside an engineering team? We'll address these, some common misconceptions, and look at some examples to provide a better idea of what technical debt is and how to handle it as an investment rather than a burden.

What is technical debt?

Let's get a common misconception out of the way: bugs ≠ technical debt. Bugs are important, immediate defects that need to be fixed right away for the product or feature to function as expected.

To understand what technical debt is, we need to look at our development process and what it's based on — three concepts of shipping software:

Valuable - It needs to make sense and solve problems for users.

Working - The software has no bugs. It's been tested and verified.

Early - Ship software as early and often as possible. This is one of the most important, because teams want to drive the product based on feedback from real users.

These guide the things teams need or want to ship in the near future. However, working software doesn't necessarily mean well-designed software. When building a new solution that doesn't already exist in a system, you probably won't invest time in making too many design decisions in the first iteration. Adding design early would result in shipping software slowly and infrequently. The odds of building the wrong design are too high, and in the long run, incorrect design decisions are worse than the original code. It's all about making fewer decisions and adding less structure to keep options as open as possible.

This deferred code design is technical debt, and there's an implicit agreement that teams will have the time and space to pay this debt. As feedback comes in and teams have more context and knowledge, they can make the best investment in "crystalizing" the code into a specific design.

Intentional vs. unintentional technical debt

You'll sometimes hear technical debt framed as the result of poor coding practices or mistakes, but this isn't necessarily true. A useful way to categorize technical debt is:

Intentional debt — This is strategic. Intentional technical debt allows teams to work faster with the ability to meet critical deadlines at the expense of future obligations. There is an implicit understanding that this debt will need to be repaid in the future.

Unintentional or accidental debt — This is unplanned. It's typically a result of unexpected changes, lack of expertise, or insufficient planning.

Teams should do everything possible to avoid unintentional debt, and use effective management to ensure they maintain control over all technical debt while continuing to ship software early and often.

Understanding technical debt

There are a couple of commonly-used metaphors that help explain intentional technical debt:

The typical loan metaphor - Technical debt behaves like a loan. You take out some capital now with interest to pay over time, and you pay it back later.

In terms of technical debt, you get to ship changes faster at the expense of improving the design at a later time, with the tradeoff that it becomes harder as time passes and your application grows around the added code.

The unhedged call option - You sell someone the option to buy an agreed quantity of something in the future — let's say a ton of bananas, at a fixed price of 50¢ per kilo. You're betting that when the buyer actually buys the bananas, the price of the bananas is going to be lower than the price now, and you're going to get the premium. The buyer gets the guarantee that they're going to get bananas at a fixed price, so it removes the uncertainty of fluctuating prices, demand, and availability of the product.

This is a simplified explanation of an unhedged call option, but it better captures the unpredictability of technical debt (for a more nuanced take on technical debt as an unhedged call option, we recommend reading this post by Steve Freeman). In terms of technical debt, the bet we make is that we won't ever have to change this call — we collect the premium now and never have to sell it to assume any costs. If we never see that code again, then we're ahead, and any efforts to improve its design would be a waste of time and resources in retrospect.

However, this can cause issues. What we're assuming here is an unlimited risk, because odds are that that part of the code will require changes in the future. For example, if a high-profile customer demands a new feature, those quick fixes we bet on just became difficult to work with. And if it's combined with tight deadlines or other issues like team member turnover, it can quickly become very challenging.

Dealing with technical debt

How you handle technical debt is ultimately up to you, your team, and your product. If you use it as a strategic tool, you'll be able to build software that meets your customers' needs today, while keeping your code base prepared for future opportunities. This makes technical debt a valuable strategy for everyone in a company, from product development and marketing to engineers.

Teams can create long-term stability while using technical debt through:

Aligning with the product roadmap - This ensures investment in code design is made to support upcoming features or technical initiatives. Having robust, cutting edge features makes your offering more marketable.

Focusing on small, manageable delivery cycles - Ensures a high chance of doing something about technical debt without disrupting product development.

Prioritizing debt repayment based on business goals - Ensures you're concentrating your efforts on the areas that matter most by focusing on parts of the codebase that are critical to upcoming projects.

A tool for strategic growth

All projects and products accumulate technical debt, whether it's intentional or not. If you consider it strategically, and plan for technical debt, it becomes a tool for strategic growth rather than a burden.

You can read in detail how DNSimple deals with technical debt, along with advice on paying back your technical debt, in this post. And stay tuned for part two, where we'll explore how we view and manage technical debt at DNSimple.

If you have more questions, or want to talk about how DNSimple can help you achieve the easiest domain management possible, drop us a line — we'd love to help.

Not using DNSimple yet? Give us a try free for 30 days to explore our integrations and multiple features that ensure your domain management is as simple and secure as possible.

Share on Twitter and Facebook

Guillermo Gutiérrez

Father, husband, software developer, amateur cook and baker, coffee enthusiast, maker aficionado, and Oxford comma fan.