Prerequisites & Discovery Inputs
Have the following assets, repositories, and architectural context accessible before executing this evaluation:
- Deployment logs and build history
- Development velocity metrics
- Support ticket analytics
Problem Statement
Technical debt silently drains developer velocity and increases operational expenses. This tool provides a checklist to classify, trace, and size technical debt in legacy codebases.
When to Use
Appropriate when engineering teams report that new features take longer than expected or when maintenance effort begins consuming the majority of developer bandwidth.
Step-by-Step Guide
Step 1: Gather Operational Symptoms
- Collect velocity trends from project tracking tools.
- Identify files or modules that require frequent patch deployments.
- Audit tribal knowledge constraints (systems only one developer understands).
Step 2: Classify Complexity Types
- Map technical debt into structural, functional, or testing debt.
- Track duplicate implementation patterns across modules.
Step 3: Quantify the Drag
- Size the cost of delay (how much slower changes are in complex systems).
- Calculate operational risk costs (potential downtime from brittle logic).
Checklist Items
- Velocity trends show a decline in features delivered per sprint.
- Releases require manual verification steps instead of complete unit tests.
- At least three modules depend entirely on single-person knowledge.
- Database queries are hardcoded directly inside templates or view layers.
- Third-party packages have gone un-updated for over 12 months.
Architectural Invariant · Production Hardening
Architecture specifications are only as sound as their verification in running production. In high-throughput systems, ensure every interface boundary maintains isolated timeout budgets, automated fallback circuits, and zero reliance on unmetered external dependencies.
Frequently Asked Questions
Practical insights on modernization executionIs all old code considered technical debt?
No. Old code that continues to execute reliably without requiring maintenance or impeding new features is not technical debt.