Yes, architecture is a big bottleneck, because the majority of our time is spent reading code rather than writing it (and now, with AI, similar issue - AI has to spend time reading code before it makes changes).
"Reading" is at different levels - system level architecture, component level architecture, class design, and method implementations. Thye all need to be optimized to reduce maintenance costs.
Thanks for sharing! Could you elaborate further on "The last point is where I've put most of my energy recently — building Calyntro to surface exactly this from git history."
We parse the full git log — every commit gives us: author, timestamp, and the list of files touched. That's the raw material.
For knowledge concentration, we count commits per author per file. If one person is responsible for 80% or more of the commits to a file over time, that file is flagged as a silo.
Roll that up to module level and you get a silo ratio per module — a number, not a feeling.
We ran this on the MongoDB open-source repository.
One developer accounts for 1,551 commits across 116 files in a single module. No secondary coverage. That's not a guess — it's directly in the history.
For hidden coupling, we look at co-change frequency: which files appear together in the same commits, and how often.
Files that repeatedly change together have an implicit dependency — regardless of what the architecture diagram says.
That's the "changing this always breaks reporting" pattern made visible.
The output is a ranked list: here are your highest-risk modules, here's who owns them, here's what they're coupled to across team boundaries.
No surveys. No manual mapping. Just the history the team already created.
If you want to see it on a real codebase: demo.calyntro.com — no login required.
Architecture becomes the real bottleneck.
Yes, architecture is a big bottleneck, because the majority of our time is spent reading code rather than writing it (and now, with AI, similar issue - AI has to spend time reading code before it makes changes).
"Reading" is at different levels - system level architecture, component level architecture, class design, and method implementations. Thye all need to be optimized to reduce maintenance costs.
"Only Mike understands billing" — that's not just a people problem. It's measurable.
When 80%+ of the commits to a module come from one person, that's a knowledge silo.
Git history records it commit by commit — long before Mike hands in his notice.
"Changing this always breaks reporting" is also in the log: billing and reporting co-changing in the same commits, across years, across teams.
Nobody documented it, but the codebase did.
The mental map experienced developers carry exists in the git log.
It just needs to be read.
Yes, knowledge silos are a huge problem. What are some strategies you've tried to tackle this problem?
The first step that actually worked for me: stop guessing where the silos are.
Most teams think they know — but when you look at the commit history, the real concentration is often somewhere unexpected.
A module nobody worries about, owned by one person for three years.
Once you have the map, three things help:
Deliberate review routing — PRs for high-silo modules go to someone who doesn't own them. Slow at first. Worth it in the end.
Pairing on the scary modules — not as a general practice, but targeted at the files with the highest knowledge concentration.
Making the risk visible to leadership — "only Mike knows billing" lands differently when you can show it as a number.
That's when it gets prioritized.
The last point is where I've put most of my energy recently — building Calyntro to surface exactly this from git history.
Happy to share more if useful.
Thanks for sharing! Could you elaborate further on "The last point is where I've put most of my energy recently — building Calyntro to surface exactly this from git history."
The process is simpler than it sounds.
We parse the full git log — every commit gives us: author, timestamp, and the list of files touched. That's the raw material.
For knowledge concentration, we count commits per author per file. If one person is responsible for 80% or more of the commits to a file over time, that file is flagged as a silo.
Roll that up to module level and you get a silo ratio per module — a number, not a feeling.
We ran this on the MongoDB open-source repository.
One developer accounts for 1,551 commits across 116 files in a single module. No secondary coverage. That's not a guess — it's directly in the history.
For hidden coupling, we look at co-change frequency: which files appear together in the same commits, and how often.
Files that repeatedly change together have an implicit dependency — regardless of what the architecture diagram says.
That's the "changing this always breaks reporting" pattern made visible.
The output is a ranked list: here are your highest-risk modules, here's who owns them, here's what they're coupled to across team boundaries.
No surveys. No manual mapping. Just the history the team already created.
If you want to see it on a real codebase: demo.calyntro.com — no login required.