Software Complexity Metrics
Much of the work that I do involves developing applications that assist in solving engineering problems. Since I do the project management aspects of this (as well as lending a hand in the actual writing), I recently counted the number of lines of code in the largest project. (I was a bit surprised to find that it was almost 200,000, which is quite large by my organization's standards.) But what was I really trying to measure?
I was, of course, trying to measure complexity.
Everyone knows that lines of code are simply not a good way of measuring programmer productivity. It doesn't take into account the requirements of the application. (I.e. more complex applications need more lines of code, usually.) Thus, people have proposed alternatives to measuring software complexity, such as feature counts (also known as function points), and (perhaps better) testable requirements counts. Still, some have pointed out that the number of lines of code can be related to the amount that one can manage in one's mind, at a given point in time. In other words, we are not trying to measure productivity, we are trying to measure complexity.
Lines of code is really an easy metric. Just run the whole source directory through a utility like wc, and out pops a little number.
The other metrics are somewhat harder to determine. Function points have the flavour of arbitrariness about them. The number of requirements needs a requirements document (a good thing, of course), but requirements change as the project matures. The number of test cases is a very good measure for some aspects of the project, but care must be taken that there are not multiple tests for the same feature.
It would seem like lines of code (like programmer hours, or money invested) is a "cost" term. The completed features (like the number of test cases, etc) is a "benefit" term. Projects with a high benefit to cost ratio are doing well.
Perhaps either the cost term or the benefit term can be used to measure the complexity of the program. Programs with large number of features are going to be more complex. Similarly, programs with a large amount of code are also going to be complex. (That complexity may be warranted.)
(All of this assumes a reasonably-complete program. The prediction of complexity, based upon a set of requirements, is another question entirely.)