When you think about debt in a business, you think about the money: rate, principal, term, covenants. Most of the debt in a business doesn’t come with tidy numbers, though.
When the mechanic says “you’ll pay for that later if you don’t take care of it now,” that’s debt. Sometimes you should take it. Deferring a non-urgent repair might be what lets you make the trip this month. Sometimes you shouldn’t. Defer everything and you break down on the highway at a much higher cost. What you want in that moment is a mechanic you trust who will tell you which is which.
Software works the same way, and it matters more, because the consequences stay invisible right up until they aren’t.
What technical debt is
Technical debt is the result of sacrificing long-term goals for short-term gain. A team takes a shortcut to hit a date. A developer builds something the quick way because the right way would take a week they don’t have. A framework falls three versions behind because upgrading isn’t anyone’s priority.
None of that is automatically wrong. It’s a tool, and it can just as quickly become an anchor. Three things decide which: the type of debt, how much you already carry, and when you take it on.
What it costs you
Like any other debt, it has principal and interest.
The interest is the time your team loses every day working around old decisions. A change that should take an hour takes a day. A bug fix breaks something else. New developers take months to become useful because nothing is documented.
The principal gets paid when someone goes back and rebuilds the code to reflect what’s now known. Developers call it refactoring. To an owner it looks like spending money to get nothing new, which is why it gets deferred.
An example from one of our engineers. He took over a system where the client regularly needed more data added to a particular screen. The previous team had trained the client to expect a week per request. He spent about a week refactoring the code around that screen. After that, each request took under five minutes. The client had been paying a week of interest every time; now they paid a week once. That story is not unusual. When the interest gets high enough, it eats all the other work and the system stops moving. That’s usually when we get the call, and the owner describes it as the software stopped working for us.
How to tell if you have it
You don’t need to read code. Signs an owner can see from the outside:
- Work arrives in lurches instead of steady progress
- Simple changes to common things take far longer than seems reasonable
- The team spends more time fixing bugs than shipping improvements
- Bugs that were fixed come back
- Nobody can produce current documentation
- There are no automated tests and no manual QA step before a release
- Developers know about problems and ship anyway
- The team talks openly about “the debt,” but nobody tracks it or pays it down
- Your team or partner gets no ongoing training
Any three of these together is worth a closer look.
The four kinds
Martin Fowler’s technical debt quadrant is the most useful way to sort it. Debt is either deliberate or inadvertent, and either reckless or prudent.
- Reckless and deliberate. Quick and dirty, with no plan to fix it. This is how a project gets set on a course for failure, usually because someone made an unreasonable demand and nobody pushed back.
- Prudent and deliberate. A conscious shortcut to hit a date, with a plan and a budget to pay it back. This is the good kind.
- Reckless and inadvertent. The team didn’t know better and piled up debt without realizing it. Often the team lacked the breadth for the problem.
- Prudent and inadvertent. The team did everything right and learned enough along the way to see how it could have been done better. Unavoidable, and healthy if it gets paid.
Inadvertent debt can’t be eliminated, but code reviews, testing at every stage, and a team that keeps learning keep it from surprising you. Reckless deliberate debt is the kind to refuse outright.
When taking it on is the right call
Sometimes it is:
- Being first matters more than being best. If the window closes, a shortcut with a payback plan beats a perfect system that arrives late.
- The work is a throwaway. A proof of concept designed to be discarded carries its debt out with it.
- You might abandon the idea. Not every idea wins. Ship the smallest useful version, learn, then invest in what’s working.
- Something is on fire. A partial fix for a live critical bug today beats a complete fix next week.
In each case, weigh the new debt against what you’re already carrying. Timing alone isn’t enough; the type and the total matter too. A shortcut on a clean system is a decision. The same shortcut on a system already drowning in interest is a surrender.
How to manage it
- Ask your team or partner to name the debt and track it. If it isn’t on a list, it isn’t being managed.
- Require code reviews, testing at every stage, and ongoing training. These are the cheapest debt limiters there are.
- When you take on deliberate debt, budget the payback as part of the project, not as a future favor.
- Be wary of technology chosen because the developers are comfortable with it. A hammer is not always the right tool for a job.
- Work with a team that wants to understand your business, not just your ticket. Misunderstanding the domain is where the most expensive refactors come from.
- Keep interest low by letting the team refactor a little, continuously, while it’s cheap.
If you suspect you’re carrying a lot
If you own a system and three or more of the signs above apply, the right first step is a System Evaluation: one to four weeks, fixed fee, and a plain-English read on how much debt you’re carrying, what it’s costing you, and whether the answer is paying it down in place, a planned modernization, or a rebuild. If the system is mid-build and has stalled under its own weight, that’s project rescue. Book a discovery call and we’ll tell you which.