I agree that you can extract some info from these LOCs. I was also curious if I can extract something useful and this is why I could give you those numbers. In particular case of this project, I don't believe these numbers say anything. Or, more precise: I can get much more useful info by analysing the code directly from other points of view.

There is another draw back of LOCs: once people understand how their code is evaluated, they will work to optimize the evaluation and not to have good code. The maintenance solutions will be chosen depending on the evaluation calculus and not the real goal.

Vlad

>As the Maintenance Project Manager, I can potentially discern some important things about the different modules that you worked on. Module (.prg, vcx, whatever) number one that you worked on took 16 hours for you to "touch" 30 lines of code. [change traffic per hour = 2 lines/hr] ratio of Module number two that you worked on took your four hours to "touch" 470 LOC. [change traffic per hour = 117 lines/hr.]
>
>So, what would the statistics show if I tracked these numbers for the modules over a period of a month/quarter/year? Would I see that Module 1 has very high maintenance hours to ACT ratios? Does Module 2 have a low hours/ACT ratio? If I also follow that up with a measurement of the cyclomatic complexity of the module, would I find that the complexity of module 1 was higher than that of Module 2? How would the quality of documentation for these two modules correlate to these numbers?
>
>If I have a backlog of modification requests for Module 1, I can potentially offer some empirical advice to the owner about the efficiency of modifying, versus completely rewriting the module.
>
>I agree that LOC is not a silver bullet. These examples require metrics beyond merely LOC. I'm just arguing that LOC are not "totally useless."
>
>Marty