Glossary

accruing interest—Additional costs incurred by building new software that depends on an element of technical debt, a nonoptimal solution. These costs accumulate over time into the initial principal to lead to the current principal (accretion).

artifact—See development artifact.

business goal—A high-level objective that a stakeholder in a software product development effort wants to achieve.

cause—The process, decision, action, lack of action, or event that triggers the existence of a technical debt item.

compounding interest—See accruing interest.

consequence—The effect on the value, quality, or cost of the current or the future state of a system associated with technical debt items.

context—The set of economic, sociological, cultural, and technical factors that are not strictly under control of the project but have a strong influence on the project evolution.

cost—The cost of developing or maintaining a product, which mostly consists of paying the people who work on it. Cost is often approximated for planning purposes by using a system of points as a proxy for actual financial cost.

developer—Any person involved directly with the development of software: architects, designers, coders, testers, and so on.

development artifact—An element of a system or the supporting work products: design, code, documentation, tests, defect records, and so on.

feature—A chunk of functionality that delivers business value.

interest—See accruing interest and recurring interest.

point—A unit of measure of the development cost of a planned system.

principal—The cost savings gained by taking some initial approach or shortcut in development (the initial principal) or the cost it would take now to develop a solution (the current principal).

product—A complete system that is ready to be delivered or commercialized.

quality—The degree to which a system, component, or process meets customer or user needs or expectations (IEEE Standard 610).

recurring interest—Additional costs incurred by a project in the presence of technical debt, due to reduced productivity (or velocity), induced defects, or loss of quality (maintainability and evolvability). These are sunk costs that are not recoverable through remediation.

registry—For a software system, an inventory of technical debt items typically stored in a tool, such as an issue tracker or project backlog management system.

remediation—The removal of a technical debt item. Its cost is the associated current principal and any accrued interest associated with it.

stakeholder—Any party—person or organization—that is affected by or that influences a development project.

symptom—An observable qualitative or measurable consequence of technical debt items.

system—A set of connected, engineered artifacts that form a complex whole. In this book, system refers to the software-intensive system under development that will ultimately become the product.

technical debt—1. The complete set of technical debt items associated with a system. 2. In software-intensive systems, design or implementation constructs that are expedient in the short term but that set up a technical context that can make a future change more costly or impossible. Technical debt is a contingent liability whose impact is limited to internal system qualities, primarily, but not only, maintainability and evolvability.

technical debt description—A systematic way of capturing a technical debt item and its (known) properties.

technical debt item—One atomic element of technical debt connecting a set of development artifacts with consequences for the quality, value, and cost of the ­system and triggered by one or more causes related to process, management, ­context, ­business goals, and so on.

value—The business value derived from the ultimate consumers of the product: its users, or acquirers, the people who are going to pay to use it, and the perceived utility of the product.