>I agree that it may be usefull for your point 1. I disagree with point 2.
>
>My job is development as well as maintenance. The percentage of each one varies form 50-50 to 90-10. But I don't see any way to measure the maintenance using LOC. This month I fixed 2 bugs to an old project. I added about 20 lines of code and modified about 10. It took me almost 2 days. The previous maintenance of the same project involved about 70 new lines of code, more than 400 changed. All this for about 4 hours. IMHO, LOC doesn't apply here.
>
>Vlad

Vlad,

I think you and I are very close to agreement on this. I agree with you that merely saying, "Hey look, ACT of 30 LOC" is worthless. The scenario you outlined does identify some VERY interesting questions though.

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