Technical debt is one of the most apt metaphors in software development. It’s so apt, in fact, that it might deserve an accounting system of its own. The widespread use of AI coding tools has made technical debt cheaper than ever to accrue, but skills gaps and a lack of awareness could make it harder to pay down than ever.
Monetary debt is easy to understand: When you borrow money, you are using tomorrow’s income to meet today’s financial needs. Most organizations and nearly all individuals are no strangers to financial debt. Individuals use bank loans to make capital investments in college, automobiles, and houses, and credit cards to cover routine expenses like groceries, vacations, and gas. We also intuitively understand that debt must be repaid. If it’s not repaid, your bank will come after you.
Technical debt is best understood as using tomorrow’s product development cycles to pay for today’s technology needs.
- Technical debt is incurred when stopgap solutions are put in place. Sometimes we know it’s a stopgap, other times we think we have a permanent solution but are proven wrong. Either case is technical debt.
- It’s not technical debt if you use it just once and then throw it away, like a data migration script or a working prototype.
- Complexity, for example an SSO integration that’s used by just one client, isn’t necessarily technical debt just because it gives us a headache, it’s only debt if the solution is a stopgap awaiting a better long-term solution.
- If it breaks the product, it’s not technical debt, it’s just broken.
Businesses often incur debt to pay for capital improvement projects — in software, new products can incur technical debt when they implement provisional solutions with an explicit plan to solve the underlying problem later. This could be seen as “technical leverage” or the ability to ship a more viable product with today’s development by borrowing from tomorrow’s development team or waiting to see if the predicted challenges materialize. An inefficient query might not cause problems until the application has substantial scale, an off-the-shelf React component imperfectly solves a UI challenge, or a third-party API bridges a data gap. I argue that in some circumstances, this is a smart use of resources, provided that the plan to solve the problem later is explicit and well-understood by developers and stakeholders alike. Teams working under market-driven time pressure — startups being the most obvious example — need this leverage.
Where technical debt becomes more problematic is when it’s used like working capital and not paid off rapidly, as if you maxed out a credit card and made the minimum payment each month. Like monetary debt, technical debt can accrue interest, although the interest rate of technical debt is essentially variable and indefinite since it depends so much on future decisions. Regardless, any sort of debt gets more expensive to pay off the longer you wait. For example, new features can become tightly coupled to a stopgap solution, the team forgets exactly the tradeoffs they made, and eventually, it can feel like technical bankruptcy is the only path forward. In fact, “tear it down and start over” is exactly the decision that many development teams make when faced with this scenario. Understandably, this is even more common when the developers didn’t incur the debt themselves.
Managing Technical Debt
- Don’t ship anything you don’t understand, even as a stopgap.
- When you think you’ve accrued some technical debt, write it down. Two implementations I’ve seen are markdown files Github repositories, and user stories in a Jira backlog.
- Educate product leadership on the tradeoffs you’ve made and advocate for a solution where resolving technical debt might result in higher velocity.
Shipping AI-generated code to production without a complete understanding of what it does and why is an easy way to introduce future issues that could be very difficult to resolve. You could accrue debt without even thinking about it. In personal finance, so long as we pay our balance in full each month, we can use credit cards to cover routine expenses and come out ahead in airline miles or cash back. There are no reward programs for technical debt.
Developers often face challenges in quantifying technical debt and in making the issue visible. I’ve heard product stakeholders throw up their hands and say “I don’t want to hear about technical debt! If it works, it works, we need to ship valuable features to our users!” Rarely, they’re right. Most of the time, they’re missing a key point of velocity — teams tend to move faster over time when they work clean.
As a thought experiment, product development organizations could develop an internal ledger for technical debt. The currency might be story points. Sophisticated agile organizations might develop a sense of a healthy debt ratio. When debt is incurred, an estimate of the “right way” solution can be added to the ledger as an epic, which can be decomposed into stories and paid down over time.
Technical debt can be healthy, but awareness across the product organization is crucial to leveraging it.