Does the number of lines of code a good measure of a programmer's productivity?

The main concern being brought in is whether then number of lines of code being made by a programmer is the correct method of measuring his productivity. And as a reply, I truly think not. Although there's definitely some relation with productivity and lines of code, but it's far from direct thus source lines of code is the poorest and most ineffective way of measuring one’s productivity.

In Wikipedia, programming productivity is defined as a variety of software development issues and methodologies affecting the quantity and quality of code produced by an individual or team. From this definition alone I can adhere that my opinion is well justified since number of lines only refers on quantity and does not directly relate to quality of coding or work done.

Source lines of code (SLOC) is useless if we use this software metric in programmers doing the same design but different languages since different languages can produce different numbers of lines of code for implementation of the same design. If a same program is to be done in Java and C++, it can be foreseen that Java programmers can create lesser lines of codes than C++ programmers since it has more built in functions and classes than C++ (or vice versa depending on the program to be done). From this example, we can say that even if the quantity of code is lesser but if the quality is the same therefore the programmer is still productive.

Source lines of code (SLOC) is also rendered ineffective when the code is still not complied, tested or implemented, simply stated “Productivity in lines of code cannot be measured until implementation begins.” Why? Basically because a programmer could write hundreds SLOC but then if it is wrong then should one still consider that as productive? This situation is analogous to a question “Would you measure a chef on the volume of spaghetti used per day?” Clearly not.

Furthermore, if one keeps using SLOC as software metric to measure a programmer’s productivity, a programmer may just type away or just may structure code to meet productivity goals. Which in reality it refers that no serious work is done.

From my experience, the trend nowadays is to make your source line of code shorter but still keeping up with the quality of the program. Shorter and more concise programs make it easier for programmers to debug and manage their programs. The best programmer is generally the one who takes the most code away, not the one who adds the most code. A measure of when a product is stabilizing is when it "turns the hump" from growing to shrinking code size.