Technical debt
Technical debt is the accumulated cost of shortcuts taken during development — code that's harder to change than it should be, missing tests, outdated dependencies, or architectural choices that no longer fit. The metaphor (coined by Ward Cunningham) treats it like financial debt: interest compounds until you pay down principal.
Healthy teams distinguish deliberate debt (a known shortcut, taken to ship faster, tracked for repayment) from inadvertent debt (the code degraded because nobody saw the trade-off). Anti-patterns: treating all 'old code' as debt; using debt as an excuse to avoid shipping; or doing a 'tech debt quarter' that ships zero customer value. The pragmatic approach is paying down debt on the lines you're already touching — boy-scout rule, refactor on the way through.
Long-form posts that explore technical debt in depth — when to use it, common failure modes, how AI helps.
- Should engineers write ADRs for every architecture decision?Yes — the bar isn't 'big decision', it's 'would a new engineer six months from now wonder why we did this?' Most teams under-write ADRs.8 min read
- How to migrate from Confluence to a structured doc toolThe 30-day playbook for leaving Confluence. The hard part isn't the content move — it's deciding what NOT to move.10 min read