Technical Debt
Shortcuts that speed today's work borrow against tomorrow's; unpaid, the interest compounds until change becomes nearly impossible.
A Useful Metaphor
Technical debt is the accumulated cost of choosing a quick or expedient solution over a better one that would take longer. Like financial debt, it can be a sound investment when taken deliberately and repaid soon, and ruinous when it piles up unacknowledged. The interest is paid in slower future work and rising risk of error.
Where It Comes From
- Deadline pressure: a shortcut to ship now, meant to be fixed later.
- Evolving understanding: code written before the problem was fully understood.
- Skipped tests or documentation that must eventually be added.
- Duplicated logic and tangled dependencies that make every change risky.
Deliberate vs Accidental Debt
Debt taken knowingly, with a plan to repay, is a legitimate engineering choice. Debt accumulated through carelessness or drift is the dangerous kind, because no one is tracking it and no one has budgeted to repay it. The first step in managing debt is making it visible: naming the shortcuts and their eventual cost.
The Compounding Problem
Unpaid technical debt compounds: each new feature built on a shaky foundation is harder and riskier than the last, until the system resists change entirely and small requests take enormous effort. In scientific code, debt often shows up as brittle scripts and undocumented assumptions that no one dares touch, freezing a project's ability to improve its own methods.
Managing It
Debt is managed by paying it down deliberately, refactoring, adding tests, writing documentation, before it strangles progress, and by not taking on more than can be tracked. For research code that a program will depend on for years, treating debt as a real, budgeted cost rather than an invisible one is what keeps the code able to evolve with the science.