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

Question

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....

Answer 1

pretty bad (-: A much better idea would to cover the test cases, rather than code...

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

as a bonus .. do a coverage ( conditionals coverage is better than line coverage here ).

Answer 2

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 3

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 4

SLOC can be changed dramatically by putting extra empty lines ("for readability") or by putting or removal of comments. So relying on SLOC only can lead to confusion.

Answer 5

Answer 6

Why SLOC is bad as an individual metric of productivity:
Think of code as a block of clay/stone. You need to carve, say 10 statues. It's not how many statues you carve that counts. It's how well you've carved it that counts. Similarly it's not how many lines you've written but how well they are functioning. In case of code LOC can backfire as a metric this way.
Productivity also changes when writing a complex piece of code. It takes a second to write a print statement but a lot of time to write a complex piece of logic. Not all fingers are equal.

How SLOC can be used for your benefit:
I think SLOC for defect % is a good metric. Yes the difficulty level comes into play but this is a good parameter that the managers can throw around while doing business. Try to think from their perspective too. They don't hate you or your work, but they need to tell customers that you're the best and for that they need something tangible. Give them what you can :)

Answer 7

You don't judge how good(how many features,how it performs..) a plane is based on its weight(sloc).

When you want your plane to fly higher, longer and perform better, you don't add weight to it. You replace parts of it with lighter/better materials. You strip off parts you don't need as to not add unnecessary weight.

Answer 8

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 complicated something gets the harder it is to understand it.
2. The more lines there are to read the harder it gets 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.

Answer 9

Why don't they understand that the SLOC hasn't changed, but the software does more than it did yesterday because you've added new features, or fix bugs?

Now explain it to them like this. Measuring how much work was done in your code by comparing the lines of code is the same as measuring how many features are in your cell phone comparing it by size. Cell phones have decreased in size over 20 years time while adding more features because of technological improvements and techniques. Good code follows this same principal as we can express the same logic in fewer and fewer lines of code, making it faster to run, easier to maintain, and simpler to understand as we improve our understanding of the problem and introduce new techniques for development.

I would get them to focus on the business value returned through feature development, maintenance, and bug fixes. If whoever is happy with the software says they can see improvement don't sweat the SLOC.

Go read this:

http://stackoverflow.com/questions/3800707/what-is-negative-code