Measuring Technical Debt: Beyond SonarQube

Source: Dev.to

Limitations of SonarQube

SonarQube tells you about code smells, but it doesn’t reveal hidden coupling such as a billing service that shares a database table with an auth service—an undocumented relationship known only to a single engineer who is about to leave.
That’s the kind of technical debt that actually hurts.

What Traditional Code‑Quality Tools Measure

• Cyclomatic complexity (function‑level)
• Code duplication
• Test‑coverage percentage
• Style violations
• Known vulnerability patterns

These metrics are useful but superficial. A codebase can score A+ on SonarQube and still be an operational nightmare because the real debt is structural, not syntactic.

Structural Debt

Typical symptoms

• Unwanted coupling between services.
• Shared database tables between services that were meant to be independent.
• Feature flags that never got cleaned up and now control many code paths.

How to Measure Structural Debt

• Cross‑feature dependency count – number of edges connecting 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).

Knowledge Debt

Symptoms

• Tribal knowledge that isn’t documented (e.g., “ask Mike”).
• Code areas understood by only one person.

How to Measure Knowledge Debt

• 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.

Architectural Debt

Symptoms

• A monolith that should be decomposed.
• Service boundaries placed incorrectly.
• Over‑patched abstractions that are harder to understand than the code they wrap.

How to Measure Architectural Debt

• Change coupling – files that always change together but belong to different features (suggesting a missing abstraction).
• Churn rate by feature – high‑churn features evolving faster than their architecture supports.
• PR size distribution – consistently large PRs in a feature may indicate a misplaced boundary.

A More Actionable Dashboard

Instead of a single 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.

These insights are what Glue’s team insights and code health features provide: system‑level intelligence about real risks, not just syntax‑level metrics.

Turning Metrics into Decisions

• High knowledge risk 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.