SonarQube tells you about code smells. It doesn't tell you that your billing service is coupled to your auth service through a shared database table that nobody documented, and the one engineer who understands the relationship is about to leave.
That's technical debt. The kind that actually hurts.
These are useful. They're also superficial. A codebase can score A+ on SonarQube and still be an operational nightmare because the real debt is structural, not syntactic.
The Three Debts That Matter
1. Architectural Debt
This is coupling that shouldn't exist. Services that depend on each other's internals. Shared database tables between services that were supposed to be independent. Feature flags that never got cleaned up and now control 15 different code paths.
How to measure it:
Cross-feature dependency count: how many edges connect features that should be independent?
Coupling ratio: internal dependencies / external dependencies per feature
Circular dependency detection: services that depend on each other (A → B → A)
2. Knowledge Debt
This is tribal knowledge that hasn't been captured. Code areas where only one person understands the behavior. Systems where the "documentation" is "ask Mike."
How to measure it:
Bus factor by feature: how many people have committed to each feature in the last 6 months?
Knowledge concentration: % of code authored by the top contributor per feature
Review coverage: % of PRs in each area reviewed by someone other than the author
3. Evolution Debt
This is the gap between how the code is structured and how it needs to be structured. A monolith that needs to be decomposed. A service boundary that's in the wrong place. An abstraction that's been patched so many times it's harder to understand than the code it was supposed to simplify.
How to measure it:
Change coupling: files that always change together but are in different features (suggests they should be in the same feature, or there's a missing abstraction)
Churn rate by feature: high-churn features are evolving faster than their architecture supports
PR size distribution: if PRs in a feature are consistently large, the feature boundary may be wrong
A Practical Technical Debt Dashboard
Instead of a SonarQube grade, imagine a dashboard that shows:
Feature health grid: Each feature scored on complexity, coupling, knowledge concentration, and churn
Risk hotspots: Top 10 files by (churn × coupling × single-author %), ranked by production incident potential
Knowledge risks: Features where >80% of recent commits come from one person
Dependency anomalies: Cross-feature dependencies that have grown in the last quarter
Evolution pressure: Features with high churn but low test coverage — the most likely sources of future incidents
This is what Glue's team insights and code health features provide. Not syntax-level metrics — system-level intelligence about where your real risks are.
From Measurement to Action
Technical debt metrics are only useful if they drive decisions:
Knowledge risk high in billing? → Schedule a pairing session with the solo contributor before they go on vacation
Cross-feature coupling increasing? → Prioritize a refactoring sprint to clean the boundary
High churn + low coverage in auth? → Add integration tests before the next feature push
The difference between "we have technical debt" (everyone knows this) and "we have 3 knowledge-concentrated features, 2 coupling anomalies, and 1 high-churn area with zero test coverage" (actionable intelligence) is the difference between complaining and fixing.
Keep Reading
SonarQube measures syntax-level debt. The real debt — architectural complexity, knowledge concentration, dependency rot — is a form of the Understanding Tax that compounds over time.
Glue measures what SonarQube can't: feature-level coupling, knowledge concentration risk, and dependency anomalies. This is pre-code intelligence applied to technical debt — structural metrics derived from your actual codebase, not just syntax analysis.