Table of Contents for

Your Code as a Crime Scene

Evaluate Communication Costs

To reason about communication costs, we need to know who’s communicating with whom. The analysis model we’ll use is based on the idea that we can identify a main developer of each module.

We’ll define the main developer as the programmer who’s likely to know the most about the specific code. Because code knowledge isn’t easy to measure, we’ll use the number of contributed lines of code instead.

Like all heuristics, our metric has its flaws—in particular, since we measure something as multifaceted as programmer contributions. That doesn’t mean the results are useless; the metrics are there to support your decisions, not to make them for you. Your knowledge and expertise cannot be replaced by data.

So sure, using the number of added lines of code is a rough approximation, but the overall results tend to be good enough. Let’s see the metric in action.

Identify Main Developers by Removed Code

Since we used the number of added lines to identify main developers, this means that a copy-paste cowboy could easily conquer parts of the codebase. So, let’s turn it around and find an alternative. Good programmers take pride in doing more with less. That means you could use the number of removed lines of code instead. That tweak to the algorithm would identify developers who actively refactor the code. Since Code Maat implements the analysis, refactoring-main-dev, go ahead and try it yourself. In practice, you’ll often find that in projects that care about code quality, like Hibernate, the two algorithms identify the same people. This is why we used the conceptually simpler metric of added lines in our case study.

Identify Main Developers

As the following figure shows, the contribution information is recorded in every commit. We just need to instruct Code Maat to sum it up and calculate a degree of ownership for each entity. The author with most added lines is considered the main developer, the knowledge owner, of that module.

You perform a main developer analysis with the main-dev option. On Hibernate, this analysis will deliver a long list of results. (Remember, Hibernate is a large codebase.) So let’s save the results to a file for further inspection:

Let’s look inside main_devs.csv to find the main developer of AbstractEntityPersister:

The results identify Mr. Ebersole, the productive project lead on Hibernate, as the main developer. In our analysis period, he contributed 695 of the 1,219 lines that have been added to AbstractEntityPersister, an ownership of 57%.

Remember, we’re after expensive communication paths. So who does Mr. Ebersole have to communicate with? To find out, we need to identify the main developers of the modules that are temporally coupled to AbstractEntityPersister. Let’s look at that.

This Only Works on Git

The main-dev analysis we ran only works on Git. The reason is that neither Subversion nor Mercurial includes the number of modified lines of code in its log files. Fortunately, there’s a workaround that’s almost as good. If you’re on another version-control system—for example, Subversion—then run the main-dev-by-revs analysis instead. That analysis classifies the programmer who has contributed the most commits to a specific module as its main developer.

Analyze Contributions to Coupled Modules

When we analyzed the temporal coupling to AbstractEntityPersister in the ​code​​​, we identified three dependent modules. Let’s extract the main developers of those from our main_devs.csv analysis results:

As you can see in the preceding figure, all entities that have a temporal coupling to the AbstractEntityPersister are within the mind of the same developer. Looks good—or does it? The low ownership degree, 39 percent, of EntityPersister.java indicates that the code is shared between several authors. Let’s see how much each programmer contributed before we can feel safe.

Calculate Individual Contributions

The contributions of each developer are available from the same version-control information. We just need to use an entity-ownership analysis instead. Here’s how it looks, filtered for EntityPersister:

Oops—one of the programmers, Eric Dalquist, uses two committer names. We see it immediately in the output above, but Code Maat had no way to know. That means we’ve run into our first analysis bias!

The problem is easy to fix once we’ve identified the authors with multiple aliases. On your own projects, you want to investigate and clean the log before any analyses. Once we’ve done a quick search-and-replace on our data, we rerun the analysis on the cleaned log:

The algorithm now identifies the correct main developer. If we put our results together, we can start to reason about communication:

1. We have a temporal coupling between EntityPersister and AbstractEntityPersister.

2. Since AbstractEntityPersister is a hotspot, we know we need to modify the code frequently.

3. That means its coupled part, EntityPersister, will need to change often as well, but the two modules have different main developers!

Let’s look at the consequences.

Check Communication Dependencies Against Your Organization

Hibernate is open source with a development process that’s different from what most companies in the industry use. Without more context and insight, it’s hard to reason about the consequences of our findings.

What we do know is that communication costs are likely to increase with organizational distance. So when you identify a case like this in your own projects, you want to check the information against your organization. Are the two programmers on the same team? Are they located at the same site? If not, it may be a concern.

When we work together, we develop informal communication channels. We meet in the hallway, grab a coffee together in the morning, or chat about our work during lunch breaks. If we lose those opportunities for informal talks, our products suffer.

In this chapter, you got the basic tools to start analyzing how well your own development work aligns with those communication channels. Let’s sum up.