Remove/rewrite paragraph on McCabe complexity as fraud

[david-a-wheeler]

Remove/rewrite this paragraph because it makes false claims:

A metric that assigns a value to individual functions (i.e., its value is calculated from the contents of single functions) cannot be used as a control mechanism (i.e., require that values not exceed some limit), because its value can be easily manipulated by moving contents into newly created functions. The software equivalent of what is known as accounting
fraud in accounting.

The example proves the value of the McCabe metric, instead of the claimed "manipulation". McCabe complexity measure estimates complexity by estimating the difficulty of testing (by estimating effort for branch coverage). The original function had 16 paths, requiring 16 tests for branch coverage. The new set of 4 functions can each be fully branch unit tested with 4x2=8 tests. You would typically want to test the combination (e.g., with integration tests), but that combination would typically not need as many tests (because you have confidence in the units). Reduciing the number of tests that need to be developed across an entire project can have substantial economic value. What's more, what each function does is almost certainly clearer (though obviously it'd be better to measure that).

The McCabe complexity measure is showing, correctly, that splitting up functions tends to make each function easier to test. It's plausible that easier-to-test is also easier-to-understand, though that's a different question.

Obviously you want the McCabe complexity measurement to measure something different than what it measures. That's fine, but complaining that it measures something different than what you want it to measure is irrelevant. It's not accounting fraud; saying it's fraud is demonstrably false.

[Derek-Jones]

The original program (main function) contains 16 paths and 16 tests are required to cover each path. If we assume that functions a to h each contain one path, then the program can be branch covered in 16 tests.

Splitting the main function up into four functions does not change the number of possible paths that could be executed through the program. However, if we only count paths at the function level there only appears to be 4x2=8 paths.

Splitting a function up only makes it easier to test that function if the impact of the functions it calls are ignored. For instance, there will be paths through the sequence of function calls a_b, c_d, e_f and g_h that are not covered by the 4x2 tests.

McCabe's original paper uses the same verbal slight of hand that most subsequent researchers have used. He starts off talking about program complexity (all well and good), and then switches to discussing a tool that calculates his metric for individual subroutines.

People say that McCabe reduces program testing effort, which it does because it reduces the effort for by causing some functions to be split up. What rarely gets pointed out is that fewer paths through the program are tested. It is accounting fraud.

[david-a-wheeler]

What rarely gets pointed out is that fewer paths through the program are tested.

This statement is true but irrelevant. Unit tests don't test whole programs.

[Derek-Jones]

What do unit tests have to do with this discussion?

McCabe's metric numbers might be considered during unit testing, but that does not validate the metric in any way.

It may be the case that the estimated cost of testing is too high and some way of reducing it is required. The McCabe metric might be used as a justification for splitting functions and just testing the new split-up program, with the tester accepting that less thorough testing has been done, but it is within budget.

In this case, the role of McCabe's metric is to blind management with techno-babble, so they think everything is ok, and overlook that less testing has been done (which is to be expected on an inadequate budget).