My previous post explained How to count the LOC of your .NET application and Tim B and Keith answered that LOC should never be counted because it is not useful. I don’t agree at all.
Often developers get stressed when we talk about LOC because some company unfortunatly use LOC as a yardstick to assess developers productivity. LOC has nothing to do with productivity: you can create 1000 LOC in a day by creating a Form with many controls and it can also take 2 days to correct a hard bug that will be fix by changing a single line.
First, LOC is useful to compute the automatic test coverage ratio, since coverage necessarily represents a fraction of LOC.
Second, LOC and especially logical LOC is useful to estimate software. Estimation in software is a difficult task. In his excellent book Software Estimation Demysitfying the Black Art, Steve Mc Connell explains well that LOC is the most efficient way to compare applications that have been developed within the same context. You can then use this comparison to plan new development, refactoring, migration etc… For example it is interesting to know that the code base of Windows Vista (around 70M LOC) is roughly 100 times bigger than the .NET framework codebase (around 500K LOC).
Estimating software is a complex subject because the estimation is not proportional to LOC, the bigger a codebase is, the higher it costs to add a new feature.