I’ve mentioned articles by Phillip Armour of Corvus International (Deer Park, IL) before: he writes a regular feature in Communications of the ACM called “The Business of Software” and normally features some of the tougher, management-oriented problems of development. This month he tackles how software is measured and points out the ridiculous use of “Lines of Code” or LOC.
(Of course, LOC could also mean “Loss Of Consciousness” or “Loss of Crew” or, using loc. cit. as the source, simply “loco”. Thanks to Stammtisch Beau Fleuve)
LOC is how many lines will have to be written, or were written, for a particular software application. This is analogous to measuring the size of a house project by how many nails it will take. It makes some sense, but not much. The complexity of the project, experience of the staff and ability to reuse or shortcut all affect the LOC count. A similar measure is Function Point Analysis.
Armour argues that LOC is simply a metric. A collection of metrics may indicate a particular size but only taken together. He suggests that using a collection of metrics would better allow managers to estimate the actual size (think worklength in manhours and elapsed time).
Phillip G. Armour (2004). “Beware of Counting LOC [Lines of Code]”. Communications of the ACM, (Mar 2004) 47(3):21-24.
Image Credit: Typists. By Lewis W. Hine (1874-1940). ca. 1915. George Eastman House Collection.