Technical Debt
Technical debt describes design or implementation limitations that create present or anticipated extra work. The affected changes and operating conditions matter: an isolated limitation need not add effort to every later change. Ward Cunningham introduced the debt metaphor in his 1992 WyCash experience report to explain the value of shipping, learning, and consolidating an implementation, and the burden of leaving that consolidation undone.
Cunningham’s account explains a deliberate tradeoff, but deliberateness is not a requirement for every debt item in the broader usage here. SEI’s work on identifying debt connects concrete software artifacts to accumulated or expected extra work. A limitation may come from a conscious shortcut, incomplete understanding, or later changes in context. Identify its consequences rather than calling every imperfection debt.
Sources and possible remedies
| Source | How it arises | What repaying looks like |
|---|---|---|
| Deliberate shortcut | A known limitation accepted for a short-term benefit | Record affected work and review whether reducing the limitation is worth the cost and risk |
| Learning | New understanding exposes a limitation in an earlier design | Improve the affected part where the expected benefit justifies change; learning alone does not require a rewrite |
| Unnecessary diversity or integration workarounds | Choices create avoidable duplication, coupling, or support burden | Compare integration improvements and selective consolidation with the requirements each technology serves |
| Deferred maintenance | Unaddressed compatibility or support changes increase later effort or exposure | Plan updates against coverage and risk, comparing transition, testing, and certification costs; frequent small moves are not always cheaper |
DORA warns that unconstrained technology choices can increase maintenance effort and fragility. Those costs become evidence of debt when they can be tied to a particular design limitation and extra work that an improvement could reduce. A second database needed for a distinct workload has normal operating costs that are not automatically debt interest. Technology standard explains how scoped choices and review can manage variety without assuming every difference should be removed.
Making the interest visible
For each debt item, identify the artifact, limitation, affected work, and feasible improvement. Estimate both the improvement cost and the avoidable burden of leaving it in place. The following observations help locate that burden; they need attribution and comparable workloads before being treated as estimates of interest.
- Change cost in the affected area: compare similar changes and separate extra work caused by the limitation from differences in complexity, testing, or staffing.
- Incident contribution: identify whether the limitation caused or prolonged incidents. Appearance in an incident review alone does not establish that relationship.
- Specialist dependency: investigate whether an opaque design makes change unnecessarily dependent on a few people. Cunningham described extreme specialization as a possible consequence of an unconsolidated implementation; some specialist work is intrinsic to the domain.
- Repeated operational work: toil can expose recurring workarounds. Attribute only the burden caused by the identified limitation to that debt item; not all manual work or normal service operation is debt interest.
Compare the expected avoidable burden over the system’s remaining useful life with implementation and transition cost, uncertainty, and the risk of the change. Mandatory maintenance or unacceptable exposure can require action even when a simple cost comparison favors delay. A system about to retire may justify containment rather than a large refactoring.
Getting repayment onto the schedule
Maintenance capacity can support recurring updates, while work already planned in an affected area may make a design improvement practical. A larger replacement may need dedicated funding and coordination. Funding it as a project does not require a single cutover: parallel operation, staged migration, or expand-and-contract may reduce transition risk where compatible interfaces and state handling make those approaches feasible.
GOV.UK’s 2018 Open Standards principles recommend estimating exit and migration costs at project start and planning transitions for systems that can no longer be modified. These are public-sector planning examples; exit cost alone is not proof of debt. A legacy system can reflect loss of support, changed requirements, or unacceptable cost and risk as well as design limitations. Deprecation explains how to communicate and manage retirement.
How debt relates to standards, exceptions, and team autonomy is worked through in A Standard Nobody Could Deviate From.
References
- Ward Cunningham, The WyCash Portfolio Management System, OOPSLA 1992 experience report — the origin of the debt metaphor.
- DORA, Capabilities: Empowering teams to choose tools — how unconstrained technology choices add debt and operating cost.
- GOV.UK, Open Standards principles (updated 5 April 2018), published under the Open Government Licence v3.0 — estimating exit and migration costs, and not extending systems that can no longer be modified.
- Stephany Bellomo, SEI, Got Technical Debt? Track Technical Debt to Improve Your Development Practices (2016) — concrete artifacts, design limitations, and accumulated extra work.
Discover more from Insightful Data Lab
Subscribe to get the latest posts sent to your email.