Unit 11 — Software Quality & Technical Debt

Learning objectives

• Reason about functional suitability, performance, compatibility, usability, reliability, security, maintainability, and portability.
• Distinguish useful metrics from vanity metrics.
• Explain technical debt as a trade-off with future consequences.

Quality is multidimensional

Improving one attribute can affect another. Strong encryption may add CPU cost; aggressive caching may complicate consistency; generic abstractions may improve reuse but reduce simplicity.

Metrics need interpretation

Examples include defect density, change failure rate, lead time, test execution time, complexity, coupling, code churn, and escaped defects. A metric is most useful when it supports a decision.

Goodhart's law in practice

When a proxy metric becomes a target, teams can optimize the number rather than the underlying quality. For example, forcing a coverage percentage can produce low-value tests.

Technical debt

Technical debt can be intentional or accidental. Track debt when it is likely to affect delivery, reliability, security, or maintainability. Record the consequence and a plausible repayment strategy rather than only labeling code "bad."