 9:33:08 PM Code counting metrics should give a big bonus for negative lines of code - they're vastly more effective than the other kind.
However you look at it, each line of code you write adds at least one more potential bug. Excess code is bad. Simple is good. Reuse is bliss.
Sometimes I've managed to drop hundreds of lines of code in a day - especially when debugging and troubleshooting other people's code. Obviously, someone "achieved" ten times the "productivity" by pasting the same code ten times instead of using a subroutine. Over time, though, you end up with one fix in four of those copies, and another in three ...
Even with new code, you can often generalize the existing code to get improved functionality from fewer lines.
Finally, one of the smartest things a programmer can do is to use other people's components. Sure, you *could* write your own XML parser, and "produce" thousands of lines of code --- and thousands of bugs (and lines of code for patches) etc.
We all know that, but I've never had much luck convincing management that less is better. After all, quality is hard to measure, but lines of code is easy. The same managers who like to track the number of hours spent on each task tend to like counting code. ["What do you mean, you spent three days working on it and you only wrote two lines of code?"].
By the way, I think lines of code is a meaningless concept to start with - how does one line of assembler code compare to one line of APL? |
"Data! data! data!" he cried impatiently. "I can't make bricks without clay."
