Do you use hotspot analysis to prioritize tech debt?

Not all bad code is equally bad. A messy module that hasn't been touched in three years poses far less risk than a slightly messy module your team changes every week. Yet most teams either try to fix everything (impossible) or ignore everything (dangerous).

The key insight: bad code only hurts you when you need to change it.

The hotspot principle

In most codebases, roughly 5% of files receive around 90% of all changes. These high-churn files are your hotspots — and they're where code quality problems translate directly into bugs, slow delivery, and developer frustration.

Stable code that is rarely or never modified is largely harmless, regardless of how it looks. Refactoring it consumes time and introduces regression risk with little return. Refactoring a hotspot, on the other hand, pays dividends every time your team touches that file.

How to find hotspots

Git history is your best source of truth. Run this command to rank files by change frequency:

    {`git log --format=format: --name-only | sort | uniq -c | sort -rg | head -20`}

Figure: Find the 20 most frequently changed files in your repository

This outputs a ranked list of files by number of commits that touched them. The top results are your hotspots — prioritize these for cleanup.

Alternatively, you can use AI to work this out for you.

Bad example — refactoring the wrong code

❌ Figure: Bad example - Refactoring stable, rarely-changed code wastes effort and introduces risk

Good example — targeting hotspots

✅ Figure: Good example - Targeting the most-changed files delivers the highest return on refactoring effort

Watch out for survivorship bias

Hotspot analysis has one important blind spot: teams sometimes avoid touching genuinely problematic code, making it invisible in change frequency metrics. A file with zero commits might be well-designed stable code — or it might be a fragile landmine everyone is too afraid to touch.

Combine hotspot data with:

• Team intuition — ask developers which areas of the codebase they dread
• Code review findings — note recurring complaints in PR comments
• Bug reports — trace bugs back to their source files

Tools

• CodeScene — provides automated hotspot analysis with visualisations, team coupling metrics, and trend data
• git-quick-stats — lightweight CLI for commit frequency analysis
• Your Code as a Crime Scene by Adam Tornhill — the definitive book on this technique, applying forensic analysis methods to software archaeology