“If you can’t measure it, you can’t manage it.” Not so fast! Internal software metrics, or code metrics, have their history in software engineering. We love to measure software development because it makes us feel as though we are really in control. But, given a number, how does it change what we do or think or how we proceed? The most sought-after goal of the software engineering community is finding ties between metrics and software quality aspects. This paper claims that code size is the only valid metric.

In particular, the study tests 26 metrics as predictors of three external features: instability, change complexity, and bugginess. As the study reveals, “the more a metric is correlated with size, the more able it is to predict external features values.” For example, to predict the amount of work programmers will spend in a change task, you do better to rely on lines of code (LOC) or number of tokens (NOT) metrics than cyclomatic complexity or loop count. This conclusion comes with one main caveat: the study was conducted against 26 open-source projects and written mainly in Java.

The statistical method to validate the quality of metrics as feature predictors is Kendall &tgr; rank correlation. Another important aspect of the method is time units used. Instead of a wall clock to measure file change frequency, for example, the study uses a commits clock, which ticks with every commit operation to the software project’s repository. Such a method is justified mainly because software engineering data regularities usually evolve over time, and data can no longer be considered as independent and identically distributed.

Generally, practitioners should know that they do not need to waste time trying to understand code-metrics numbers. Further, these criticisms can be useful because they can help researchers find flaws in old code metrics and come up with new ones that are better.