Source Lines of Code (SLOC)
SLOC is used to collect data about computer programs and the people who write them. Although the mapping is not exact, SLOC can be used to approximate the effort spent on a project. Comparing the SLOC before and after a software change can also give one an idea of the magnitude of the change and why it may have taken as long as it did.
SLOC breaks down as a metric as a program ages. Should copy-pasted lines count as much as freshly-written ones? What about lines that are copy-pasted and then lightly edited? And how does one account for lines that are removed only to be replaced with a more efficient set of lines? SLOC is inexact, but it's one of the only coding metrics available (the other being person-hours spent).
Jurph says At what scale do SLOC become a useful approximation?
I think SLOC is useful for only one thing: counting the number of lines of code in a program. Sure, we all talk about one line changes, but you can't measure complexity in lines of code. Compare a 1000 line Lisp program with a 1000 line C++ program. Unless you're a Lisp guru, the C++ program (assuming it's well-written) is exponentially easier to understand.
For a true measure of complexity that actually equates to dollars spent in some meaningful way, person-hours spent solving the problem combined with experience level is much more meaningful. After all, if all I had to do was a quick find-replace that changed 300 lines, my ESLOC (editied SLOC, this one may be unique to my place of business, I'm not sure) is 300, but my employee level 1* person-hours spent is 0.1. Using this information, management can actually calculate how much a change cost because my salary is known to them, and when it comes down to it, they're interested in metrics because they want to know where the money's going.
*Employee level 1 is a nice way of saying I currently work at the bottom rung of ye olde corporate ladder.