Picture a marketing lead who asks for one new field on a sign-up form. Two years ago the same team added a whole page in a day. This time the answer is three weeks, and nobody in the room can say why in a sentence. Nothing is broken. The site is up, orders arrive, the team is working hard. The work has simply become slow in a way that does not show on any report.
That slowness has a name. It is technical debt, and it is worth understanding even if you never read a line of code, because you are the one paying it.
What technical debt is
Technical debt is the extra work every future change costs because of how the system was built or left. The term comes from Ward Cunningham, who used it in 1992 to explain to his managers why working software still needed rework: "A little debt speeds development so long as it is paid back promptly with a rewrite." The danger, he wrote, is when the debt is not repaid, and time spent working around not-quite-right code becomes interest.
The comparison holds up well:
- The principal is the work that was skipped: the shortcut, the upgrade put off, the test never written.
- The interest is what you pay each time someone touches that part of the system: longer estimates, more faults, more checking by hand.
- Default is the point where a change is no longer slow but impossible without rebuilding something first.
Debt is not the same as bad work. A team that ships a simple version to meet a launch date, knowing what it left out, has borrowed sensibly. The trouble starts when nobody wrote down what was borrowed.
Where it comes from
Martin Fowler sorts debt along two lines: whether it was taken on deliberately or by accident, and whether the decision was prudent or reckless. In practice a business owner meets four sources.
- Deadlines. A shortcut taken on purpose to ship on time. Reasonable, if it is recorded and paid back.
- Learning. The team understands the problem better now than when it started. The early parts reflect the old understanding.
- Age. Nothing was done wrong. The platform, its plugins and the browsers around it moved on, and the system did not.
- Neglect. Upgrades skipped for years, fixes layered on fixes, and one person who knows how it all fits together.
The third is the one that surprises people. A website left untouched still accumulates debt, because everything it depends on keeps changing. We look at the kinds in more detail in types of technical debt.
How to tell whether yours is a problem
Every working system carries some debt, so the useful question is whether the interest is now larger than the cost of paying it down. You can judge that without opening the code. Ask five things.
- Do estimates for small changes keep growing, with no change in the team?
- Does a fix in one place break something unrelated?
- Are there parts of the system nobody wants to touch?
- Is there a version upgrade that has been "next quarter" for more than a year?
- Would the work stop if one particular person left?
One yes is ordinary. Three or more means you are paying interest every week, and it is time to put numbers on it. Measuring technical debt covers how.
A worked example
Take an invented but typical case: an online shop built seven years ago on a page-builder theme. Each campaign added a plugin. Today there are forty, and six of them have not been updated by their authors in years. The platform's own upgrade is blocked because two of those six would stop working.
The principal here is small and specific: replace two plugins, remove the unused ones, upgrade the platform. The interest is what the shop pays in the meantime: slow pages, security notices nobody can act on, and three weeks for a form field. Seen that way the decision is not "should we invest in technology" but "which is cheaper, the repair or another year of interest".
Sometimes the answer is a repair. Sometimes the debt is so spread through the system that a rebuild costs less, which is a separate decision with risks of its own, covered in when rewriting a legacy application is the wrong call.
What to do this week
- Ask your team for a list of the shortcuts and overdue upgrades they already know about. They have one, written or not.
- Next to each item, write what it slows down or puts at risk, in business terms.
- Pick the two items with the most interest and ask what paying them down would take.
- Agree a small, regular share of each month's work for repayment, so the list shrinks instead of growing.
If the list is long enough that a rebuild is on the table, that is the point at which an outside assessment earns its fee. Our website modernization work starts with one, and you can read a full sample assessment to see what it covers.
Sources
- Ward Cunningham, The WyCash Portfolio Management System, OOPSLA 1992 experience report.
- Martin Fowler, Technical Debt Quadrant, 2009.
Keep reading
Application modernization: what it means and when to do it
Application modernization in plain terms: what it is, what it is not, the signs a web application needs it, and how to start without betting the business.