A Guide to Technical Debt
When you need to buy a car and you don’t have enough money, you take out a loan and incur financial debt.
When you need to release software quickly, you might cut some corners. Maybe you decide to delay fixing non-critical defects or take a few shortcuts when writing the code. It’s messy, but you can fix it later, right?
That’s when you’re leveraging technical debt.
And eventually, that debt is going to come due.
Like financial debt, technical debt isn’t necessarily a bad thing—unless you let it build up. If you’re not careful, it can have a drastic impact down the line.
Let’s take a closer look at technical debt—how to leverage it effectively and keep it manageable.
What is Technical Debt?
Technical debt is a backlog of work that results when business interests determine that faster software delivery is a higher priority than perfect code.
Sometimes called design debt or code debt, the term covers everything from defects to legacy code to missing documentation.
Many times, technical debt is leveraged to meet a deadline. When the release date is critical, software developers must triage defects and planned functionality to determine what they need to get done before release.
Once the must-have work is prioritized, the rest is set aside for later updates or the next version of the software. The delayed work becomes technical debt.
The term was created by Ward Cunningham, one of the authors of the Agile Manifesto. He used it to explain to non-technical stakeholders why resources needed to be budgeted for refactoring. Since the stakeholders were in the financial industry, he borrowed the idea of debt from their world to help them grasp the concept.
As the term gained popularity, software professionals began to clarify and debate the definition. A 2014 white paper published by the Software Engineering Institute, Towards an Ontology of Terms on Technical Debt, defined technical debt as “the increased cost of changing or maintaining a system due to shortcuts taken during its development.”
Is Technical Debt Bad?
If you go by the Software Engineering Institute’s definition, technical debt may seem like a bad thing. But technical debt isn’t inherently bad.
If you’re being pressured to develop and ship fast—say, to beat a competitor to market or make a hard release date—taking shortcuts and leveraging technical debt may help.
Most video game developers take this approach, releasing a game that still needs work and issuing patches and updates for weeks after release.
Startups also need to get a product to market quickly. You can’t start earning revenue without a product release.
In these and similar situations, technical debt can be beneficial—at least in the short term.
So when is technical debt bad? It depends on who you ask.
The business interest often sees technical debt in terms of trade-offs. Their biggest concern is maintaining product quality. As long as the product meets their minimum qualifications in terms of features and quality, they’re okay with taking shortcuts and incurring technical debt.
Development often doesn’t want to agree to any technical debt at all, because they know it’s going to create more work for them down the line. To development, eliminating technical debt is often harder than simply writing clean code the first time.
To make matters worse, the business doesn’t want to allocate time and resources to eliminating technical debt, because they don’t see it as a problem. The product works, so they want to push ahead with new features that drive revenue growth.
It can be very difficult for technical architects and project managers to communicate the importance of eliminating technical debt to management—which goes back to why Cunningham coined the term in the first place.
In order to clarify good debt and bad debt, Martin Fowler—another of the Agile Manifesto authors—created a technical debt quadrant.
To Fowler, technical debt could be categorized in four ways:
Reckless and Deliberate: The team needs to get the software released and is willing to take every shortcut they can, regardless of the impact down the road.
Reckless and Inadvertent: The team takes shortcuts, not fully realizing the impact the shortcuts will have later.
Prudent and Deliberate: The team leverages technical debt in order to meet their goals, but has a documented plan to reduce the debt later.
Prudent and Inadvertent: The team isn’t intentionally leveraging technical debt, but they expect it and have a plan to address debt later, knowing some debt is inevitable.
Why Eliminate Technical Debt?
There are many reasons why you should eliminate technical debt early, but it boils down to this: The longer you wait to fix it, the harder it gets.
For one thing, defects take longer to resolve—even simple ones. It involves sorting through mounds of poor-quality code written by several developers. This also impacts the implementation of those new features the business is so eager to deploy.
When too much technical debt builds up, the code may be too rotten to tweak. Then developers are forced to rebuild the code from scratch, which eats up even more time and resources.
And here’s the kicker; that can lead to even more technical debt. If the product owner doesn’t allocate enough time and resources to pay down technical debt, development might just create another messy patch and wait until they have more time to fix it right. Then they never come back to fix it right, so the amount of smelly code increases.
Lower Your Debt
It’s almost impossible to avoid technical debt, but there are ways to keep it low.
First off, acknowledge that you’ll always have some technical debt, and that’s good. It means you’re delivering business value quickly. The key is to make sure the compromises you’re making add the most value and incur the least amount of debt. Don’t let the trade-offs you make become an excuse for lazy development.
Second, create a project plan for technical debt. Create product backlog stories that deal with fixing technical debt and have teams commit to tackling a defined percentage of that work in each sprint.
Make sure your plan includes giving developers the time and resources they need to work on technical debt, too. “When we have downtime” isn’t going to work, because most teams never have enough downtime to properly tackle debt. Set up refactoring sprints or a maintenance release that focuses on reducing technical debt and define how much technical debt the team will cover in that sprint or release.
Finally, technical debt looks different from company to company. Give your team time to refresh their knowledge of good coding practices and discuss among themselves what technical debt means to your organization. The goal is for the team to form a shared idea of what it means and how to keep it manageable.
If you keep technical debt to a minimum, it’s far easier to eliminate it. But like that car loan, once you start missing payments, the debt builds up fast and you end up with a codebase that’s unmanageable.
