Why this series
Technical debt is the most common reason software organisations slow down for no apparent reason. The teams are capable and people are putting in the hours, yet every sprint is harder than the last, estimates slip, releases become risky, and adding developers doesn't help.
The technical literature on this topic is extensive, but it's almost always written by developers, for developers. This series is written for the people who run software organisations: CTOs, VPs of Engineering, CEOs who have to make decisions about investment and priorities without necessarily writing code every day. The goal isn't to turn them into refactoring experts; it's to give them the tools to recognise the problem, measure it and choose where to act.
The articles
- What it is and what it isn't: the operational definition of technical debt. The functional test for recognising it, the spectrum from micro to systemic, and the four categories that get mistaken for debt but aren't. Published on 9 April.
- How it accumulates (out on 12 April): the mechanism that turns reasonable decisions into structural constraints. Why debt builds up even in the most disciplined organisations, and how to spot the patterns before they set in.
- The signs (out on 15 April): the concrete signals in the workflow, in delivery and in the numbers visible to the business. Not metrics that need expensive tooling, but ones you can read from the organisation's day-to-day behaviour.
- How to measure it (out on 18 April): how to put a number in front of management without getting lost in metrics. Cycle time, bug rate and how to reason about the cost of the next change.
- How to reduce it (out on 21 April): the strategies that work in practice. Not the big-bang rewrite, but the incremental approach that keeps delivery moving while you work on the structure.
The common thread
The articles converge on a question that goes beyond technical debt: is the system still consistent with the organisation that produces it? Architecture, team structure and business lines that drift out of alignment generate debt simply through inertia, regardless of code quality. This is the Consistency Model: not an alternative to technical debt, but the framework that explains why it builds up and where to act first.