How bad is SLOC (source lines of code) as a metric?

Bob Cross picture Bob Cross · Sep 22, 2010 · Viewed 16k times · Source

We are documenting our software development process. For technical people, this is pretty easy: iterative development with internal milestones every four weeks, external every 3 months.

However, the purpose of this exercise is to expose things for our project management in terms that they can understand. Specifically, these non-technical managers need metrics that they can understand.

I understand our options for metrics well and have proposed a whole set (requirements met and actual costs vs. budgeted costs are two of my favorites). However, we do have some old hands involved and they tend to hang onto metrics like SLOC.

I understand the temptation of SLOC: it seems easy for non-software people to understand and it seems like the closest analog of a physical thing (it's just like counting punched cards back in the old days!).

So here's the question: how can I explain the dangers of SLOC to a non-technical person?

Here's some concrete motivation: we work on a fairly mature deployed system that has years of history behind it. As we add features, SLOC tends to stay approximately level or even decrease (refactoring removes old / dead code, new features are really just adjustments of existing, etc). To a non-programmer manager, a non-increasing SLOC in a development project is perplexing at best....

Clarifying in response to a recent answer below: remember, I'm arguing that SLOC is a bad metric for the purposes of measuring project progress. I'm not arguing that it is a number that's not worth collecting. It requires extensive context to do anything useful with it and most program managers don't have that context.

Answer

Peter Tillemans picture Peter Tillemans · Sep 22, 2010

Someone said :

"Using SLOC to measure software progress is like using kg for measuring progress on aircraft manufacturing"

It is totally inappropriate as it encourages bad practices like :

  • Copy-Paste-Syndrome

  • discourage refactoring to make things easier

  • Stuffing with meaningless comments

  • ...

The only use is that it can help you to estimate how much paper to put in the printer when you do a printout of the complete source tree.