Technical debt: 3 signals that cost you before you see them

Technical debt never introduces itself. Nobody writes “this is debt” in a commit. You see it first in daily work: simple tasks taking three days, deployments people fear, files nobody dares to touch.

1. Small changes keep getting more expensive

The most reliable signal: compare what a trivial change costs today — a label, a form field — with six months ago. If the trend rises while the product hasn’t changed scale, the code structure is resisting change. That is the operational definition of debt.

2. The same bugs come back in different shapes

A fixed bug reappearing elsewhere is not bad luck: it is duplicated logic or a misplaced responsibility. Every local fix adds one more variant to maintain. The real fix is almost never where the bug shows up.

3. Knowledge lives in heads, not in the system

If deployment, configuration, or “why this module works that way” depend on one specific person, the system is not transferable. That is not primarily a documentation problem — it is a sign the system is too complex to explain simply.

Where to start

Not with a “big refactoring”. Measure one thing: the real time small changes take. Then remove — one duplication, one dependency, one manual step — every time you pass through. Sobriety is not a project, it is a practice.