Skip to main content

Contact

What are you interested in?

Back to Glossary (T)
Glossary · T

Technical Debt.

Technical debt describes the extra effort incurred later when a solution is built fast rather than durably, whether deliberately or not. As with financial debt, taking it on can be the right call — it only turns expensive when the interest runs alongside as permanently slower development.

TEGLOSSARYDLM Digital

Technical Debt — Explained in Detail

The image comes from Ward Cunningham and is deliberately financial. There is deliberate debt — you choose the quick option to hold a deadline and know what has to be made up later. And there is inadvertent debt, arising from missing knowledge, time pressure or changing responsibilities. It affects more than lines of code: a data structure that does not allow for the edge case, missing documentation, a manual deployment step, or a dependency not updated for years are all debt that costs interest.

It shows up as symptoms rather than as a metric. Changes that sound small always take longer. Bugs return elsewhere after being fixed. New developers take unusually long to become productive. There are places in the system nobody volunteers to work on. And the answer to new requirements increasingly becomes 'not possible' instead of 'this is what it costs'. A team saying those sentences does not have a motivation problem but a structural one — and it should be named as such rather than as a question of pace.

A typical origin story: a proof of concept demonstrates that data migration from the legacy system works. Because it runs, it is not replaced but extended — credentials hard-coded, no error handling, assumptions that only hold for the test dataset. Two years later the invoicing run depends on it, nobody knows the code, and every change is a risk. Paying the debt back then costs a multiple of what a clean rebuild would have cost at the start. This is not an isolated case but the most common pattern in grown SME systems.

How to handle it is a commercial decision, not a matter of faith. What works is a fixed share of capacity — often around ten to twenty per cent — reserved for repayment: keeping dependencies current, adding tests for the critical paths, automating manual steps. Transparency in the quotation matters just as much: if the quick option is chosen, the later effort belongs in writing. And not every debt has to be repaid. For a system that will be replaced within eighteen months anyway, living with the debt is the commercially correct answer.

Frequently Asked Questions About Technical Debt

No. Debt taken on deliberately can be right — to hold a market window or a deadline, or to test an assumption quickly. What is problematic is inadvertent debt, and the case where repayment is never planned in at all. What counts is that the decision is spoken aloud, written down, and given a point in time at which it will be paid back.

From how effort develops: when comparable changes become more expensive rather than cheaper over time, the team is working against the system. Further signs are long test phases before every release, recurring bugs, and statements such as 'that has grown historically'. Ask about test coverage for the critical flows and about the age of the dependencies in use.

Ten to twenty per cent of ongoing capacity is the figure most often cited from experience, permanently rather than as a one-off clean-up project. Regularity matters more than the exact number: small, continuous repayment is considerably cheaper than a large remediation programme that becomes unavoidable at some point and then collides with day-to-day business.

Ready for Your Project?

Apply this knowledge to your website — DLM Digital will help you.