I’ve been seeing more and more people rely on “lines of code” to measure various things in relation to a software project - its size and scope, the amount of effort required to create it, defect density, and so on.

Unfortunately, the “lines of code” measurement is a poor method at best, like measuring a painting by the number of brush strokes. It tells you nothing about the complexity, quality, or composition of the piece itself.

There are, unfortunately, few aspects of software that can be quantified in a way that suits today’s charts-and-graphs management methods, so this metric has been relied on to produce a wide variety of measurements in recent years.  While it may have some utility in comparing codebases with similar designs and styles by the same author, it is more frequently used in less meaningful scenarios.

The truth is, a million lines of code can be rewritten into less than 20,000, and vice versa. And when you take into account that most projects are developed by multiple programmers, using a variety of styles and approaches, you quickly come to the conclusion that even within a single project, a “lines of code” comparison is, at best, an arbitrary measurement criteria.

Is there a better option?. Personally, I like the idea of “use cases”, especially when it comes to measuring defect density. Defects in a physical product are measured by situations in which someone tries to use the product and is unable to do so due to a defect. Why shouldn’t the same be true for software?

Of course, figuring out all the possible ways someone could use a program is no walk in the park, but we could start by looking at some of the tools that already exist to trace logic paths in an application and identify each potential sequence of commands that could be executed.  

  (0 comments)