The technical debt metaphor provides a nice handle for a software development trade-off that’s been present in every project I’ve ever done- as a manager, architect, programmer, or tester. Ward Cunningham has done us all a favor in creating a memorable tag line. And with this popularity, everyone is of course against it. But how many really understand what drives technical debt? And that is it a symptom — not a root cause?

This is true regardless of scope: number of function/feature points, use cases, user stories, etc. Even this is under-stated: the number of interfaces increases exponentially with the number of components (programs.) That is, a system of 1000 components isn’t necessarily 10X to system of 100 components — it is often 20x or 30x. The context of usage matters in ways that are hard to appreciate unless you’ve had to live with the long-term effects of sustaining a system of programs for a user community (a product) over many releases.

Yet hope springs eternal in software development. Developers and sponsors of software projects often don’t understand this disparity, so expectations and commitments are made assuming programs instead of a systems product. Developers, managers, and sponsors all underestimate work. Then Bad Things happen. Even if a project is de-scoped and time-boxed, necessary work is skipped – that’s where technical debt starts. Then schedules slip, bugs escape, and revenues don’t come.

This is a chronic problem. If a project isn’t cancelled after an initial confrontation with reality, attitudes often harden and people begin to game each other. This usually results in more technical debt piled on top of the first tranche. That’s how technical debt gets compounded. Left unchecked, this leads to systems (and the businesses built around them) that consume more resources than they produce value — in effect, technical bankruptcy.

This vicious cycle can be broken. Preventative principles were articulated in the 1970s and have been rediscovered about every ten years since (just as each generation rediscovers sex, as friend and mentor Boris Beizer often observed.) Hundreds of software engineering and software process strategies have been worked out and applied with success to many thousands of systems. They all share certain strategies:

Understand the problem to be solved beyond vague and superficial platitudes

Devise a solution architecture (logical and physical) than can be communicated to all stakeholders (and communicate it)