The five categories commonly used to describe technical debt are code, architecture, testing, documentation, and infrastructure. They are categories of technical debt generally—not five universally recognized subtypes of architectural debt. Architectural debt specifically concerns design choices that make changes, integration, or system evolution more costly. The distinction matters: a monolith or an untidy codebase is not automatically debt; the signal is the cost and risk those conditions impose on future work.
What are the five kinds of technical debt?
A 2021 literature review describes five broad categories. The categories are useful for organizing observations, but they are not a universal standard, and only one directly names architecture.
| Category | What it describes | Example evidence |
|---|---|---|
| Code debt | Implementation-level problems, often associated with code smells. | Repeated workarounds or code that is difficult to change safely. |
| Architectural debt | Design or structural flaws that make changes, integration, or evolution more costly. | Changes repeatedly affect many components, or dependencies cross intended boundaries. |
| Test debt | Inadequate test sets or a lack of structured, automated testing. | Changes require substantial manual checking because automated coverage is insufficient. |
| Documentation debt | Missing or weak code and project documentation, including unclear APIs or inadequate descriptions of use cases and domain models. | Teams cannot reliably determine how an interface is meant to be used. |
| Infrastructure debt | Poor resource management or neglected technology and platform foundations. | Outdated foundations or platform constraints repeatedly impede delivery or sustainment. |
These categories can overlap in practice. For example, an architectural boundary problem may generate code workarounds and make tests harder to maintain. A 2021 review also discusses social and process debt as non-technical categories; they are outside this five-category list. The Software Engineering Institute (SEI) frames technical debt around future cost: “Technical debt can be defined as a design or construction approach that is expedient in the short term but that creates a technical context in which the same work will cost more to do later than it would cost to do now.” (SEI, Managing Technical Debt in Complex Software Systems.)
How do you identify architectural debt?
Look for evidence in the system’s structure and in the consequences of changing it, not just local code smells. A useful signal is change propagation: how much of the system is affected when one element changes. SEI describes propagation cost as the percentage of system elements affected when a randomly chosen element changes. It can help reveal tight coupling, but it is not a universal dollar measure of debt (SEI, Developing an Architecture-Focused Measurement Framework).
Check dependencies and boundaries
- Trace which components depend on one another, and look for cycles that make components difficult to change independently.
- Compare actual dependencies with intended component boundaries and architecture rules; violations can show where the implementation has drifted from the design.
- Notice recurring workarounds caused by structural constraints, such as components reaching into one another’s internal data or responsibilities.
Compare design records with how the system changes
Architecture documents can be out of date. Compare them with source code, repository history, issue trackers, and, where available, conversations with people who work on the system. A review of 47 studies on identifying architectural debt found that source code was used in 32 studies, evolutionary data in 16, architectural documentation in 11, human knowledge in 10, and issue trackers in 7. These are counts of studies that used each input, not estimates of how many software projects have debt (Verdecchia et al., Architectural Technical Debt Identification: the Research Landscape).
How should you record a debt item?
Capture the context while the people who understand the issue can still explain it. Each record should identify the affected system element, describe the observed condition, and state what it costs or risks. SEI recommends assessing the impact and documenting candidate ways to address the item; teams can maintain records in a debt registry or an existing backlog (SEI, Identify Technical Debt Items).
- Element: the component, service, interface, platform, or other affected part of the system.
- Condition: the dependency, rule violation, missing test, or other observable issue—not just a label such as “bad architecture.”
- Consequence: the added cost, delay, reliability risk, or limitation on future change.
- Impact and context: which teams or system elements are affected, how often the area changes, and relevant evidence such as examples from change history.
- Remediation options: plausible ways to reduce the cost or risk, including their trade-offs.
- Responsibility: an owner or responsible team, plus a place to track follow-up.
For organization-wide visibility, SEI describes a centralized registry linked to project backlogs, so teams can avoid duplicate records while keeping mitigation work close to the projects doing it (SEI, Experiences Documenting and Remediating Enterprise Technical Debt).
How do you prioritize technical debt?
There is no single validated formula in these sources for ranking every debt item. Compare the likely cost and risk of leaving the item in place with the cost and risk of addressing it, taking account of the system’s plans and context. Useful decision factors include:
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minute- Spread of impact: how widely a change propagates and how many components or teams are affected.
- Frequency of change: how often the affected area is likely to be modified, based on planned work and available change history.
- Consequence of delay: the delivery, reliability, sustainment, or opportunity cost of carrying the issue.
- Remediation cost and risk: the implementation effort and the chance that the change itself disrupts delivery or system behavior.
- Business timing: whether upcoming capabilities or system changes make now a sensible time to address it.
- Reversibility: whether the work can be staged and adjusted as the team learns.
Use these factors to explain a decision, not to produce a falsely precise score. SEI notes that measurement has no fixed universal unit, so a tool’s score should not be assumed comparable across teams or products (SEI, Strategic Management of Architectural Technical Debt; Applied Computing Review, Technical Debt Resulting from Architectural Degradation and Code Smells).
When should you refactor or rearchitect?
Choose the smallest change that meaningfully reduces the recurring cost or risk. If a problem is localized, incremental refactoring may be enough. If the architecture repeatedly blocks important changes across boundaries, broader redesign may be justified—but a large rewrite is not the default. Compare options by their expected effect on dependencies and change propagation, delivery and reliability risk, implementation and ongoing maintenance cost, reversibility, and business timing. These are practical decision axes, not a formally validated ranking scale.
Reduce coupling incrementally
Possible steps include enforcing intended architecture rules, breaking a dependency cycle, or reducing unnecessary dependencies. Where systems share internal data structures, an explicit interface can reduce reliance on those internals. Confirm the intended design and test the affected behavior as the change proceeds.
Stage broader architectural changes
For a wider rearchitecture, divide work into stages that preserve delivery safety and use tests to check behavior as responsibilities or interfaces move. The cited guidance supports systematic analysis and management, but it does not prescribe one migration recipe for every system. Let the system’s constraints and risks determine the sequence.
How should a team manage intentional debt?
A shortcut can be a deliberate way to explore or deliver sooner; the risk comes from treating that choice as permanent when the system or business context changes. Record why the shortcut was taken, what future cost or risk it may create, and a concrete revisit condition—such as a planned capability, a technology change, or evidence that the cost of change is rising. SEI’s guidance on strategic architectural debt emphasizes revisiting deliberate choices as conditions evolve (SEI, Strategic Management of Architectural Technical Debt).
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
