Performance measurement from the past is still with us . . .

Lines-of-code still being measured and estimated!

by Conrad Weisert
May 1, 2010
© 2010 Information Disciplines, Inc.

This article may be circulated freely as long as the copyright notice is included.

An old problem measurement resurfaces

Several decades ago programming managers were interested in how many lines of source code (LOC) a program contained:

  1. as a measure of programmer productivity, and hence as a way of evaluating programmer performance,
  2. as a basis for estimating the cost and duration of a programming effort,
  3. as a measure of the power of a programming language.

As the programming profession matured, however, the validity of those measures was soon discredited, and we thought it had been relegated to the distant past of Computer Science. We were wrong! I've attended several recent presentations, some by respected leaders of our field, in which the term was put forth as a useful, if secondary, measurement.

In one case the speaker displayed a table showing the number of lines of code (LOC) per function-point in a half dozen popular programming languages! He didn't explain what use these ratios might be.

The programmer's role

If the programmer's main role were simply to write and test program code, we could defend and even support counting or estimating lines of code. But that's not the programmer's role.

The programmer's role is to solve a well-defined problem, usually by using computer technology. Indeed, we should reward a programmer for not writing code, i.e. either for finding an existing solution to a problem or for writing minimal compact code.

Where are those lines of code?

Here are two ways in which a large program might contain 1200 lines of code:

A single monolithic 1200 line program 40 modules averaging 30 lines each

The difference between the two in the effort required for coding, for testing, and for maintaining the program may be huge, even an order of magnitude. The single LOC number, therefore, is meaningless without more information. A more meaningful measure cited in a 2002 article1 is the number of coupling interactions among the modules. Of course, that number, like many function points, can't be known before the design phase, so it, too, is useless for estimating effort at the beginning of a project.

Misguided incentives

If a programmer expects to be be evaluated partly on the basis of the volume of source program statements produced, then:

Why would we want our projects to provide incentives to reward bad practice? Can we retire LOC permanently?

Epilog: What is a line of code, anyway?

There's a close correspondence between lines of code and statements in a programming language. Comments and blank lines, despite their importance, aren't counted.

In assembly languages the correspondence is nearly one-to-one. In typical procedural or object-oriented languages, we don't count punctuation or other delimiters, such as { or end;, even when they occupy a separate line.

In a flexible language a single statement containing long data names may extend over multiple lines (or if it doesn't it often should). On the other hand, multiple short statements, if they're very closely related, may appear on the same line. How many lines should be counted in each of these three ways of coding this same trivial logic in C++?

 if (a[i] > a[j])
     tempo = a[i];
     a[i]  = a[j];
     a[j]  = tempo;
 if (a[i] > a[j])
    tempo=a[i], a[i]=a[j], a[j]=tempo; 
 if (a[i] > a[j]) swap(a[i],a[j]); 

Because that example is so trivial, most of us would count it as a single line2 no matter how it's laid out, but more complicated examples challenge us to make difficult judgments. Why bother?

1—Lionel C. Briand, Sandro Morasca, &Victor R. Basili: "An Operational Process for Goal-Driven Definition of Measures", IEEE Transactions on Software Engineering, December, 2002. (I'm indebted to my colleague Robert Binder for alerting me to that excellent article.)
2—or just wonder why the programmer was writing his or her own sort routine!

Return to table of contents
Return to management articles

Last modified May 1, 2010