Technical debt

What it means

Technical debt is the accumulation of quick fixes that work today but make every later change more expensive. It is taken on deliberately under deadline pressure and unnoticed without review.

It is not always a mistake. Short-term debt is worth it when the market has to be tested with an MVP. It becomes a problem when it is never repaid and keeps growing.

Technical debt is not the same as a bug. A bug means the software does something wrong; debt means it does the right thing in a way that is hard to change. A related but separate problem is an outdated platform, such as an unsupported version of a database.

How it works in practice

The symptoms are quiet: the same change takes twice as long, tests are missing, deployment is manual, and nobody wants to touch the system on a Friday. These are measurable signals, not impressions.

It is repaid gradually: reserve part of each sprint for cleaning up code, build out CI/CD and tests, and remove the most fragile piece before the next big feature.

We also see it at clients whose e-shop is linked to the accounts by a home-made script. When a VAT rate or an export format changes, an integration without tests or documentation stops working and documents get retyped by hand for a month.

What to watch out for

Rewriting from scratch sounds appealing but usually costs more than paying down gradually. The debt is not only in the code: it is also in knowledge the new version has to absorb.

Debt never shows in the budget, so management underestimates it: the cost appears only as slower development and pricier changes. When the company or the system is sold, though, the buyer finds it in due diligence and reflects it in the price.