Introduction

Technical debt is a financial metaphor that software developers use to talk to “less-technical” audiences about the hidden costs associated with a system’s architecture and codebase — such as changing requirements addressed with a quick fix, bugs deferred in favor of new development, design weaknesses, or aging third-party libraries.

Technical debt makes software resistant and costly to change, and more prone to outages, intermittent failures, and security breaches. For users, this means fixes or features they need take more time to implement. For product 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 projects that add value to the enterprise. For chief security and privacy officers, this means systems that can be exploited by bad actors. And for executives, this means systems that can’t be easily adapted to deliver new business capabilities, nor relied upon to support critical mission operations.

This toolkit is for anyone who’s involved in or impacted by software development projects, including developers, managers, executives, and others. And could benefit from greater knowledge of what technical debt is (and why it’s not all bad), how to manage it, and ways to prevent accumulating it. By the end of this toolkit, you should have a clearer understanding of technical debt and how to mitigate its harmful effects.

This toolkit is based on a series of blog posts from 18F originally written by Skylight’s Chris Cairns.