Making Software

The Results

Now that we have concrete definitions of changes and modules in each of our three systems, we can finally begin to investigate how developers work with these modules.

Change Locality

We begin our exploration with a simple question: are most changes to the code constrained to a single module? Figure 21-5 shows a histogram of the number of modules modified per change for each system, and Table 21-4 presents some summary statistics.

Table 21-4. Number of modules affected by each change

Project	% changes affecting only one module	Mean modules affected
Evolution	86.6%	1.243
Firefox	73.7%	1.577
Mylyn	69.7%	1.634

Examined Modules

When making these code changes, how many modules does a developer consult? We can answer this question quantitatively for Mylyn given the availability of task context data, but not for the other two systems.

Figure 21-6 shows the number of modules that were examined by a developer for each change. The mean number of examined modules is 2.365, with a median of 2. The mean of examined modules is higher than the mean number of modules that are actually modified (1.634), which suggests that developers occasionally consult modules that they do not end up actually changing.

If we take a closer look at the modules that are examined but not modified in each change, we find two of Mylyn’s modules stand out. In 13% of changes, a developer examined the Tasks module without changing it, and in 8% of changes the same holds for the Bugzilla module. We might ...