The other day I read a thread on some blog (sorry, I don't remember where it was) on the topic of counting lines of code to measure programmer productivity.  Fortunately, the author of this post understood just how useless this metric is.  I mean, seriously, it's just dumb.  I understand that certain organizations struggle to find a way to measure productivity but counting lines of code doesn't cut it.

There are several reasons "why" counting lines of code doesn't provide any value, so for those of you who believe you still need "something" to measure productivity consider this:

• The number of lines of code can be largely a matter of choice for the programmer since syntax typically gives us great flexibility in how we write almost anything.  For example, in .NET 3.5 I can use automatic properties and create a property on a single line, but if you're counting my lines of code I'm much more likely to skip this feature and spend a little more time to write it all out and add another ten or so lines to my code.  Here's the difference:

public string Text { get; set; }

or

private string _text;

public string Text
{
    get
    {
        return _text;
    }
    set
    {
        _text = value;
    }
}

As you can see, I added an additional ten lines of code in the second property without providing any value.  In truth, I was much less productive in the second property, but by using lines of code as a productivity metric it would appear that I'm much more productive (Yay me, I beat the system!).  Hell, I might even throw in some unnecessary validation code just to add a few lines.

• Developers would be much less inclined to refactor their duplicated code into a single, reusable method.  Why would I reduce the lines of code when I know you're counting the lines I write?  This means that now I have duplicated code which, in turn, means that any updates will have to be made in both locations.  If a bug is found in one location and I forget to fix it in the second.... you get the picture.
• Most programming languages disregard white space.  This means that I could now write that property like this:

public string Text
        {    
            get
            {
                return
                    _text;    
            }
            set
            {
                _text
                    =
                    value; 
            }
        }

I could probably go on and on but the truth is that it's not hard to understand why lines of code as a metric just doesn't make any sense.  If you're struggling for a way to measure programmer productivity I would suggest a milestone driven approach instead.  Can the programmer deliver something that works within a specified time frame?  Does it meet the requirements that were set out for it?  Whatever the case may be, counting lines of code should be eliminated altogether.  It simply doesn't provide any real metric.