Discussion on:

Counting lines of code can help measure progress

The Life-Cycle theory works pretty well to determine the overall productivity of program/system development. A lot depends on the language being used --- a very high-level language can generate hundreds of machine instructions in one line of code while another language such as Assembler may generate one for one. The amount of time to write and document each may be approximately the same but the productivity may be vastly different, including the debugging time. The debugging time has to be figured in the productivity no matter what, as well as changes interjected by the user, as any programmer can tell you may make vast differences in the overall programming time.

I enjoyed this article, and the author brought up some interesting points and has obviously successfully used this tactic as a measure of productivity.

Concerning counting lines of code, I agree with the point about not using it as a sole determination of productivity, but a couple of thoughts immediately come to mind - one, if you're comparing productivity from individual to individual, you'd have to be sure you had a coding standard. For example,
if ($this == "blah") { print $this; }
isone line of code, where:
if ($this == "blah")
{
print $this;
}
is four lines.

Also, in my experience there are times when work is performed to improve the optimization of the code or to refine it in other ways (like with iterative design) that actually decrease the total number of lines. It can take just as much time to remove code in this manner as it does to create it in the first place. I know you mentioned checking to see if the number of lines increased or decreased - I was just wondering how you could account for or justify this net change in a reporting environment consistent with the other advice the article provides.

This is one more way to measure productivity, and if you put this in your management toolbox, it can be a good thing. It does not, of course, relieve a manager from truly having to understand whether the code being written is achieving the objectives...

It would be like judging a writer on the number of words written. See the Gettysburg address for an example of one of the most concise, yet well-written addresses ever given by a president...

A pointy-haired boss that attempts to use this as the only "true" measure of productivity is going to find that their least productive people will work hard to generate more lines of code, but will still be pretty unproductive... But if all the other management evaluation is going on, someone whoreally cranks can become obvious over someone who spends most of the day playing counter-strike, but that's a topic for another conversation...

The quantity of code written by a programmer does not tell how much work he\she is doing a day it simply tells how much typing they have done. It is poor management to put quantity before quality in a product or service. Take your brick layer example, if your brick layer layed all of your bricks in 1 day for a project that should have taken 2 days and the wall is not as straight as you would like, then was that worth the money? One thing I have strived to do with teams I have worked with is to have code reviews (as simple as using WinDiff) to compare the older version of the code to the new. This allowed the entire team to see what progress the product made, and over time allowed us to simplify our application (yes, delete lines). So you should be careful what you preach because there are many managers out there that see the lines on the page as the bricks that are being but cannot tell if the wall is straight. So remember who you direct these articles to, managers who sometimes don'talways understand the where quality and quantity differ.

I want to challenge you a little. First let me say that you are right that you must consider quality as well and I believe the article stressed this was only one tool. So I think we are on the same page there.
However, how do code reviews measureperformance? I think your comments are valid but perhaps off topic since if we go back to the brick example how does reviewing the wall and perhaps removing bricks measure performance? I doubt the home builder will be happy if you are a week late because you had to remove some bricks. The home builder will expect the brick to be complete and be straight. Performance will be measured by the number of bricks and not the process of making sure the wall is straight. The straight part will be expected.

I think quality measures are a different topic than performance measures. We all want quality but at some point we have to produce as well. After all the perfect product that never gets finished on time or at all isn't going to make management happy. Balance and use of multiple tools for performance and quality (as well as a host of other tools) are needed to successfully deliver.

I think line counting is not the answer to measuring coding performance. Thou if you were able to build an intelligent script that looks at the differences in source code file content and count those differences would be almost ok. There still wouldbe the problem of code optimization. After all one can wake up several times in the middle of the night and come up with sudden ideas (and changes) that don?t decrease or increase line count or ?content difference count? (compared to a state from one day earlier).

I think kevin give us a good point to understand the counting lines of code in your developing process. but indeed it is not anything. for example, last week, I add more than 1000 lines in my problem to solve a problem. but in this week, I found outthey are not correct. may be I use 100 lines to solve it. in fact, I use a better method to finish my task but the code lines decrease.

I am not going to try to tell you another way to measure productivity but I will tell my experience with line counting as a measure. I had a boss that used line counting. Almost everyone in the group starting using very large and fancy comments for everything. Code was often larger than necessary as well. Eventually, the boss got smart and starting counting semi-colons. Since we were programming in C it seemed reasonable. Eventually, every comment had semicolons galour. Every statement had several semi-colons following it. When he started looking a code size everyone called his boss to complain because the code sizes would vary based on changes. Complex problems could take time to solve but result in only a few lines of code and so forth. I guess, if you really want a measure of performance and productivity you need to know what is going on everyday. Looking at the code at least once a week is good also. Set very short-term goals, stick to them, find out why goals aren't met and keep the project on track. I think that is the best approach.