"We have two engineers who are the only ones who can touch that file. If they leave, we’re in trouble."
If you’ve heard this in a retrospective, you’re not dealing with a staffing problem. You’re dealing with a structural signal — and your git history has been logging it for months.
Take the MongoDB codebase as an example: there’s a file called replication_coordinator_impl.cpp.
- 62 commits in the last year
- 2,273 lines of code
- Cyclomatic complexity of 926 (in a repo where the average is 53)
Every engineer working on MongoDB’s replication layer probably has a story about this file. But here’s the thing: complexity alone isn't always a dealbreaker. An ugly, complex algorithm sitting untouched in a quiet corner of your repo is fine. Nobody has to touch it, nobody cares.
High churn alone isn't bad either. A simple configuration or mapping file that changes every sprint is easy to review.
The real value is in proactively identifying High Complexity combined with High Churn.
When a file is both deeply complex and constantly changing, it becomes a critical risk point that can cause unexpected delays. In the MongoDB repo, roughly 187 files have a complexity over 100 and more than 20 commits a year, highlighting potential trouble spots.
These files are where your next unexpected delay lives:
- A 2-day ticket touches one of these files.
- The blast radius turns out to be invisible.
- Suddenly it's a 2-week investigation.
Nobody sets out to build files like this. They usually start as 50 clean lines. Then a quick validation gets added because a new module felt like overkill. Then another feature drifts in because the context was already there. Fast forward 18 months, and your senior devs are hostage to a single file.
You don't need to guess where these hot spots are in your project — the data already empowers you through your Git log.
By analyzing this pattern, you can proactively identify files that pose a high risk to your project, enabling you to address issues before they cause delays.
Here is how you can quickly analyze your Git repository in 30 minutes to identify high-risk files before they impact your next sprint: calyntro demo
Top comments (0)