Making Software

Where to Go from Here

A distribution of bugs and changes like the one in Figure 27-2 is already worthy in itself: you literally see where most activity takes place and where the most problems occur. The next interesting question is the cause of this distribution. As a manager, you will be able to explain many of the effects you see, particularly when it comes to extremes, such as the modules with the most bugs or the highest amount of change. You may also be surprised, though, at some effects that did not make it into the headlines: effects distributed all across your project and possibly related to some recurring causes.

In our experience so far, the problems on every project have their own specific causes that are related to changes and bugs (which of course motivates the need for mining project histories). Typical starting points for investigation include:

The problem domain of the component

Analyzing the APIs that components use, Schröter et al. showed that Eclipse internal compiler code is seven times as error-prone as Eclipse GUI components [Schröter et al. 2006]. Evidence like this can help not only to identify critical areas of your application but can also be used to predict the quality of new components without any history, just by looking at their used APIs.

The complexity of the source code

Complicated tasks increase the likelihood of mistakes. The more complex source code is, the more difficult it is to make changes that are defect-free. There are many ways to define code ...