Your architecture diagram shows what your system is supposed to look like. Your Git history shows what it actually does.

Those two things are rarely identical.

What Change Coupling Is

Change coupling measures how often two modules change in the same commit — without any static code analysis, without reading a single line of source code. Just commit metadata and file paths.

If module A and module B consistently appear together in commits, something connects them. Maybe it’s a shared interface. Maybe it’s a hidden dependency. Maybe it’s one team doing the work of two. Whatever the reason, the Git history captures it.

The more interesting question isn’t that they change together — it’s why, and who drives whom.

What We Found in MongoDB

We ran this analysis on the MongoDB open-source repository (~500k commits). The results surface something worth paying attention to.

208 module pairs cross team boundaries and change together regularly. These are Conway’s Law violations — not in theory, but in measurable commit data.

⚠️ MongoDB has no official team structure. The team assignments used here are simulated based on module ownership patterns. The Git history and co-changes are real.

The strongest pair: src_mongo ↔ src_third_party — Score 100 (normalised 0–100), 21,415 co-changes.

But the count isn’t the most useful number here. The direction is.

The Coupling Direction

When src_third_party changes → src_mongo also changed in 10% of commits. When src_mongo changes → src_third_party also changed in 0% of commits.

One module drives the other. The dependency is asymmetric and one-directional. A symmetric co-change pattern could be coincidence — two broadly active modules that occasionally overlap. An asymmetric pattern at this scale is structural.

This distinction matters for how you respond. A symmetric coupling might need coordination. An asymmetric coupling needs an explicit interface decision.

When Coupling Becomes Systemic

For the pair jstests_sharding ↔ src_mongo, the numbers tell a different story:

  • 4,425 coupled file pairs
  • 304 actual coordination events at commit level

At this breadth, the analysis doesn’t just flag the coupling — it recommends: “Systemic — consider API boundary.”

That’s not a metric. That’s a recommendation. When the coupling is this widespread, the right response isn’t to manage coordination better — it’s to formalise the boundary between the teams with an explicit API contract.

What This Changes in Practice

Most architecture review happens before the code is written — in design documents, ADRs, team topology discussions. That’s the right place for it.

But code has a way of evolving past its original design. Teams merge. APIs erode. Shortcuts accumulate. The architecture diagram stays the same while the actual dependency structure drifts.

Change coupling analysis runs against what the team actually did — every sprint, every hotfix, every refactor. It doesn’t replace architecture review. It tells you where the architecture has already drifted and where the next review needs to focus.

Running This on Your Repository

The full MongoDB analysis is live at demo.calyntro.com — no login required. You can explore the coupling pairs, filter by same-team vs. cross-team, and drill into the directional breakdown for any pair.

To run it on your own repository, Calyntro is fully self-hosted: → calyntro.com

No source code access required. Nothing leaves your infrastructure.