Table of Contents for

Your Code as a Crime Scene

Measure Temporal Coupling over Organizational Boundaries

The research findings from the Windows Vista study suggest that quality decreases with the number of programmers. It’s easy to see the link to Brooks’s law: more programmers implies more coordination overhead, which translates to more opportunities for misunderstandings and errors.

One way to highlight the severity of parallel work is by comparing the modules with most authors to the hotspots you identify. So let’s look back at the hotspot analysis we did in Chapter 4, ​Analyze Hotspots in Large-Scale Systems​:

As you can see, the AbstractEntityPersister—the class with the most programmers—is also our number-one hotspot. That means the trickiest part of the code affects the most programmers. That can’t be good. Let’s see why.

Interpret Conway’s Law

Brooks wasn’t the first to point out the link between organization and software design. A decade earlier, Melvin Conway published his classic paper that included the thesis we now recognize as Conway’s Law (see How do committees invent? [Con68]):

Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.

Conway’s law has received a lot of attention over the years, so let’s keep this brief. Basically, we can interpret Conway’s law in two ways. First, we can interpret it in the cynical (and fun) way, as in the The Jargon File:^[32] “If you have four groups working on a compiler, you’ll get a 4-pass compiler.”

The other interpretation starts from the system we’re building: given a proposed software architecture, how should the optimal organization look to make it happen? When interpreted in reverse like this, Conway’s law becomes a useful organizational tool. Let’s see how you can use it on existing systems.

Use Conway’s Law on Legacy Systems

As you learned in ​Optimize for Understanding​, we spend most of our time modifying existing code. Even though Conway formulated his law around the initial design of a system, the law has important implications for legacy code as well.

There’s a big difference when you need to cooperate with a programmer sitting next to you, versus someone you’ve never met who is located in a different time zone. So let’s find out where your communication dependencies are.

Start your analysis from the hotspots in the system, since these are central to your daily work. From there, identify other modules that have a temporal coupling to the hotspots. Once you know the modules that evolve together, look for the main developers of those modules. From there, we can start to reason about ease of communication. Here’s how you do it.

Calculate Temporal Coupling over a Day

To analyze temporal coupling over organizational boundaries, we need to consider all commits during the same day as parts of a logical change set. Different authors will by definition commit their work independently, so we can’t limit ourselves to modules in the same commit. We focus on a single day as a heuristic; modules that keep changing together that often over a period of time are probably related.

In the authors analysis, we identified AbstractEntityPersister as the module with most contributors. Because it’s also a hotspot, we’ll zoom in on it. Specify the --temporal-period 1 option to make Code Maat treat all commits within the same day as a single, logical change set:

The analysis results show that AbstractEntityPersister tends to change together with a bunch of other modules. Every time you make a change to the AbstractEntityPersister, there’s a 45 percent chance that three different classes will change during that same day.

The next step is to find out the main developers of the coupled modules. Once we have that information, we can compare it to the formal organization of developers and reason about ease of communication. Here’s the analysis.