Image source: National Oceanic and Atmospheric Administration

Technical debt is a financial metaphor that software developers use to talk to managers about the “hidden” costs associated with a system’s architecture and codebase (for example, changing requirements addressed with a “quick fix,” bugs deferred in favor of new development, design weaknesses, or aging third-party libraries). Technical debt costs organizations time as well as money. Recent studies, seeking to estimate the financial impact, suggest that an average technical debt of $3.61 exists per line of software code, or an average of $1.08 million per system. In 2010, Gartner estimated that the total amount of technical debt worldwide could reach $1 trillion this year. Given that the federal government builds and maintains a lot of software, it’s safe to assume that it carries a fair share of that debt.

Why care about the government’s technical debt?

Technical debt can make software resistant and costly to change, and prone to outages, intermittent failures, and even security breaches.

For users, this means fixes or features they need take more time to implement. For taxpayers, this means inefficient use of their hard-earned dollars. For program managers, this means greater risk that their debt-ridden systems become so untenable that they have to be ditched and rebuilt from scratch. For chief information officers, this means less budget and resource capacity to work on innovative projects that add value to their business partners. And for agency executives, this means systems that can’t be easily adapted to deliver new business capabilities, nor relied upon to support critical mission operations.

As stewards of taxpayer dollars and servants to the needs of the public, it’s our responsibility to avoid such issues by understanding what technical debt is and how to manage it.

Over a series of upcoming posts, we’re going to explain what technical debt is (and why it’s not all bad), how to manage it, and some ways to prevent accumulating it. At the end of the series, you’ll have a clear understanding of technical debt and how to handle it.