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

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 2 years ago.

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 1

Answer 2

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.

Answer 3

Show them the difference between:

for(int i = 0; i < 10; i++) {
    print i;
}

and

print 0;
print 1;
print 2;
...
print 9

And ask them whether 10 SLOC or 3 SLOC is better.

---

In response to the comments:

1. It doesn't take long to explain how a for loop works.

2. After you show them this, say "we now need to print numbers up to 100 - here's how you make that change." and show how much longer it takes to change the non-DRY code.

Answer 4

Explain that SLOC is an excellent measurement of the lines of code in the application, nothing else.

The number of lines in a book, or the length of a film doesn't determine how good it is. You can improve a film and shorten it, you can improve an application and reduce the lines of code.

Answer 5

Pretty bad (-:

A much better idea would to cover the test cases, rather than code.

The idea is this: a developer should commit a test case that fails, then commit the fix in next build, and the test case should pass ... just measure how many test cases the developer added.

As a bonus collect coverage stats (branch coverage is better than line coverage here).

Answer 6

The issue with SLOC is that it's an easy metric to game. Being productive does not equate to producing more code. So the way I've explained it to people baring what Skilldrick said is this:

1. The more lines of code there are the more complicated something gets.
2. The more complicated something gets, the harder it is to understand it.
3. Before I add a new feature or fix a bug I need to understand it.
4. Understanding takes time.
5. Time costs money.

Smaller code -> easier to understand -> cheaper to add new features

Bean counters can understand that.