Yes it's true. Managers love metrics. Some managers may even attend clandestine weekend meetings to come up with more useless numbers to apply to the work that developers do. As we know from the days of LOC (Lines Of Code), these fail to capture the value or productivity of developers and sometimes mismotivate developers.
There is a lighter side of metrics though. They do have a critical place in software development, however it's not for managers to measure their developers rather for developers to understand their code.
Even LOC has value, in fact it's one of my favorite metrics. It's now usually referred to NCSS (Non Commented Source Statements). This metric was once used to measure productivity as if more lines of code was a good thing. Ugh! Now we use NCSS to point out when we have too many lines of code. Imagine that, the managers had it backwards. NCSS is such a simple metric and yet it's very powerful. It's usually applied at the method level and is a clear indicator that you have large, complex and difficult to understand methods. Although there is no set number of lines per method that you should conform to, the general guideline is based on amount of time it takes to clearly understand a method. It should not take more than a couple of minutes to fully understand a method, and in my experience those methods rarely have more than 10 or so lines. Small methods that do one thing only and are appropriately named are easy to understand, so let NCSS help you find those methods that aren't.
Another indicator of complexity is McCabe Cyclomatic Complexity (aka CCI or CCN). If you're a masochistic feel free to check out the wikipedia definition, or you can just trust me and accept that it's a good relative indicator of methods that have complex execution paths. For example, a method that has many return statements, nested conditionals and loops, and maybe even a few try/catch/throw statements for good measure. The greater the number of paths through your method, the higher your cyclomatic complexity. Since good unit testing would require you to cover all paths and CCI measures the number of paths in your method, CCI can also be an indicator of the number of tests you would likely need to get good coverage. Often you will see overlap between NCSS and CCI, just by the associative nature of size and complexity.
When using metrics to understand your code or to find deficiencies, be cautious to remember that these numbers are only indicators. It's easy to see a nice number and think everything is OK. Not so. For example, another favorite metric of mine is code coverage. Code coverage tells you how many and which lines of code your unit tests are hitting and it's usually expressed in percent of lines of code and percent of branches covered. I recall joining a project and running cobertura (a code coverage tool for java) to find out the project's level of coverage. I was delightfully surprised by a relatively high number and so I went about my business of refactoring and changing code. When I eventually broke the code, I was surprised that it hadn't been detected by the extensive test suite. After some inspection I realized that just because your test hits a line of code doesn't mean that line is actually being tested. What I found were lots of tests with lots of System.out's and very few assertions. The lesson here is to let your metrics point out problems, but if they tell you all is well check up on them. There is a saying in Journalism, "If your mother says she loves you, check it out." This same skepticism should be applied when using code metrics.
