I'm not sure I can agree with the "totally meaningless" label we're assigning to LOC counts. As the project lead on a very large OOP/Procedural hybrid application, I'm coming up with more and more uses for the LOC count. I'll identify two (both of which are identified in Pigoski's Practical Software Maintenance c.1996 ISBN: 0-471-17001-1)

1. Determining Complexity: We are beginning an effort to identify selections of code as being too complex. In order to do this, we count and weight all branches in the code (IF/CASE/FOR/Etc.)[McCabe's Cyclomatic Complexity]. Steve McConnell does a good job of summarizing this process in Code Complete. In order to track this complexity, it is practically mandatory that we know how many lines of code there are in the particual procedure. A procedure with a complexity rating of 8 doesn't sound bad, unless it's only 15 lines long. The converse is also true. A complexity level of 20 is really high, but what if the routine is 1000 lines long because of some text/string wrangling? A goal of our effort is to reduce the overall level of complexity in this project. That is why we require the overall LOC count. We need some number to use for our complexity quotient (i.e. COMPLEXITY / LOC)

2. Tracking Annual Change Traffic (ACT): The owners of the system need to have an idea of what paying paying their maintenance team for. Research shows that 80% of all "maintenance" is Enhancement, not Bug Fix. How else would you report the metrics of the year's work without reporting ACT? I suppose you could report on function points added, removed, changed, but how would you track that? If you track DELETED lines, ADDED lines and CHANGED lines as the numerator and LOC as the denominator, the ACT quotient you get is meaningful. I.e., in 1997 we had an ACT of 18%, 1998 12%. Etc. SourceSafe allows you to, relatively easily, track this. We are developing a SourceSafe automation based ACT counter.

Now, I agree that these two examples are on the esoteric fringe. And, these examples refer purely to software maintenance. So, if your job is strictly to develop and then walk away, perhaps you can get by without any attention to metrics. But, as a developer who is getting called in to organize more and more VFP Maintenance efforts, I'd sure like it if more developers didn't.

My two cents worth.

Marty