The term “technical debt” has become ubiquitous in the programming world. In the most general sense, it reflects the idea that you’re doing something easy in the moment, but that you’re going to pay for, with interest, in the long run. Conceived this way, to avoid technical debt would mean to avoid taking out these “time loans” in general.
There’s a subtle bit of friction, however, when using the (admittedly very helpful) concept of technical debt to communicate with business stakeholders. For them, carrying debt is generally a standard operating procedure and often a tool, and it doesn’t have quite the same connotation. When developers talk about incurring technical debt, it’s overwhelmingly in the context of “we’re doing something ugly and dirty to get this thing shipped, and man are we going to pay for it later.” That’s a far cry from, “I’m going to finance a fleet of trucks so that we can expand our delivery operation regionally,” that an accountant or executive might understand. Taking on technical debt is colloquially more akin to borrowing money from a guy that breaks thumbs.
The reason there’s this slight dissonance between the usages is that technical debt in codebases is a lot more likely to be incurred unwittingly (or improvidently). The reason, in turn, for this could make up the subject of an entire post, but suffice it to say that the developers are often shielded from business decisions and consequences. It is thus harder for them to be party to all factors of such a tradeoff — a role often played by people with titles like “business analyst” or “project manager.”
In light of this, let’s talk about avoiding the “we break thumbs” variety of tech debt, and how NDepend can help. This sort of tech debt takes the form of “things you realize probably aren’t great, but you might not realize how long-term damaging they are.”