Git Analysis

You just fixed a bug in the payment module. Simple enough — an edge case in the calculation logic. You changed three files: the payment handler, a date formatting utility, and a config loader. Those three files have nothing to do with each other. You know that. You’ve always known it. You fixed the bug anyway, committed all three, and moved on. Because that’s just how this codebase works. Your import graph is lying to you When we talk about coupling, most developers think of import statements. You open a file, you look at what it imports, and you draw a mental map of dependencies. Clean Architecture tools do the same thing — they trace the explicit links between modules and draw you a diagram. ...

What Your Git History Reveals About Team Alignment Your org chart says one thing. Your Git history says another. They’re rarely the same. Last week I wrote about Conway’s Law as a measurement problem — the idea that every commit records not just what changed, but how your teams coordinate. That the co-change pattern across thousands of commits is a structural artifact of who talks to whom, day by day, pull request by pull request. ...

Conway’s Law was stated in 1967: any organization that designs a system will produce a design whose structure mirrors the organization’s communication structure. Fifty-eight years later, it is still being treated as a principle to design toward — not a pattern to measure in what already exists. That’s the gap we wanted to close. From Metaphor to Measurement The usual treatment of Conway’s Law goes like this: recognize that your teams' communication structure will shape your architecture, then design your teams deliberately to get the architecture you want (this is what Team Topologies calls “inverse Conway maneuver”). That’s sound advice. ...