Technical debt is a bad thing. It “… Will Kill You Dead“, or at least is a “… problem“, depending on the reference cited. Multiple Web sites (including technicaldebt.com and ontechnicaldebt.com) comment on the metaphor.

Technical debt is also a marker of a kind of vitality, as I’ll show below. One of the on-going consequences of virtualization and cloud migration is that whole new realms of computing are entering technical debt, and that is a good thing! More precisely, it has the potential to be a good thing. Here’s why:

Debt and its metaphors

Whether in the form of US student loans or South Asian farm peonage, debt is associated with misery and despair to the point of suicide. Whole religions abjure debt. Financial calamities–and banking crises specifically–inevitably result from “excess leverage“. The strongest high-tech (and other) companies are (financially) debt-free“.

Still, sophisticated economists compute that optimal debt is generally a positive value, not just zero. Debt invested has an entirely different character from debt incurred to fund current consumption. Financial lines-of-credit provide a kind of insurance to improve flexibility and protect against certain risks.

Programming incidents in the last week reminded me of these economic realities. In reviewing the source code behind applications in production, I found expressions that aren’t to my standards: programs filled with magic numbers and fragile calculations. On the other hand, these same applications meet my most important standards: they serve our end-users well, at least for now, and they were constructed in a way that made it easy for maintenance programmers to understand. Once we identified the problems, it was quick enough to replace inscrutable hard constants with human-meaningful symbolic values, and fortify the programs against future change.

If “technical debt” were an unalloyed evil, we should never have committed the original source code to our repository, and certainly not put the code into production. As Olve Maudel pointed out several years ago, however, “Technical Debt is Good“, at least to the extent it enables earlier delivery of value to customers. The metaphor itself is apt because financial and technical debt share so many characteristics: debt is oppressive when too large, but rigid adherence to freedom from debt makes work too clumsy and slow-moving to serve creative developers or the consumers of their programs well.

Software-defined agility

Whole new populations of DevOps will learn these lessons as industry moves to such new and more agile techniques as software-defined networking (SDN) and datacenter-as-a-service (DCaaS). Commenters who complain, for example, that SDN slows down packet delivery are right, but typically miss the point. Third-and fourth-generation programming languages are slower than assembler, in naive benchmarks, but we use higher-order programming languages because we’re able to achieve more with them. Similarly, SDN, DCaaS, and other virtualization highlights will help make us more nimble in rolling out effective solutions.

At the same time, debt needs to be kept in balance. In coming weeks, I’ll illustrate a few common instances of technical debt in SDN and other emerging technologies, and how good DevOps can keep technical debt from growing too large.