Bad metrics – SLOC

If this doesn’t convince you that some metrics are just terrible, nothing will

This is going to be a pretty tech-themed post, but I have a gripe with terrible metrics and the people that push for them. The image above, for those who aren’t web developers, is 16 lines of code dedicated to a favicon, and is a great example of overcomplicating things for the sake of making them complicated.

The metric I’m implying here is in the software engineering industry called Source Lines of Code or SLOC and is based around the idea that you can measure progress by counting how many lines of code a developer has contributed. If you think about it for a moment and compare what you can see above with the idea that more lines means more work done, you should start to see some holes in that argument. A quote commonly attributed to Bill Gates goes as follows:

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

The biggest pusher of this metric that I had the misfortune to run across in my university days was a Mathematics student who was completely and utterly convinced that not only was it a good metric, but that it had the upside of balancing out poor workers to good workers. If a worker knows that the amount of code is all he is judged on, surely the good workers will write more code to maintain their position, faulting the bad workers, right?

Wrong, because better code that does more has less lines than code that is poorly written and does little. For example you can add lots of extra lines of code by ignoring that fact that functional programming exists, where languages like Erlang and Haskell can condense algorithms like QuickSort down to 4 lines of code.

Furthermore, bug fixing can often reduce the total amount of lines of code when refactoring existing snippets. By having a SLOC requirement you are effectively having a requirement that no bug fixing can take place, since bug fixing can be divided as follows:

  • 70% Investigation
  • 20% Tests
  • 10% Fix

You could argue that the test could be used to recoup up SLOC but what if the test only needs 5 lines to test the cases of your change?

I also would like to point out that developers aren’t stupid, and will leave companies that don’t have an actual development cycle (that isn’t waterfall) or person capable of actually reviewing the progress made by the programmers.

The idea that SLOC should be used for a small business (the Maths student’s argument) because they can’t afford to pay someone with the skills to manage the project for the developers is beyond stupid: any kind of project that can’t afford to pay for the software engineers is going to fail, as software projects almost always exceed cost and time constraints by a big margin (as chronicled in The Mythical Man-Month).

No developer is going to want to be on a ship like that when it goes down, they’re probably going to just go work at Microsoft.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.