Let’s Do Some Engineering Pt. 2: Software Metrics

Analyzing Metrics

Of course by doing all these calculations, with tools or not, all we get is a bunch of numbers. Just like LoC, they’re meaningless in a vacuum. Figuring out what these numbers mean is the important part of metrics.

Figure 1. Keeping track of different metrics over many iterations of a project

As mentioned before, some metrics are absolute values. Metrics like cyclomatic complexity should always be below a certain value regardless of the "average" complexity of your codebase (though the actual recommendation depends on who you ask). However, most metrics, specifically those with ratios, are meant to be analyzed statistically on a relative scale in comparison to the entire codebase. Generating a boxplot is generally a good way to identify the outliers. These outliers are generally the modules/methods we want to look at because they exceed the "threshold" of normalcy in the project.

Figure 2. The box plot of LoC for methods in an application. Only outliers are shown.

Keeping track of these metrics allows us to analyze our project’s history, giving us even more statistical data to work with. We can analyze, for instance, which methods/modules change often, and we can perform meta-calculations on our data to find out the outliers in those categories. This lets us decide if, perhaps something needs to be done about those methods/modules to make them more stable. Keeping track of these metrics also lets us figure out how our team works, how effective they are and such, which lets us estimate effort for future projects of similar scope (again a future article subject).