Everyone has heard horror stories about pointy-haired-bosses counting lines of source code to track the progress of a project. We roll our eyes and laugh at their stupidity. But before you laugh too much, you might want to find out whether you’re really any better.
Most of what software projects measure are not things we care about. Not things we really care about. Do you really care about the number of coding standard violations in your code? About compiler warnings? About test coverage? About cyclomatic complexity?
No, you only care about the presumed effects of these metrics. What we really care about are things like how much it costs to change the system, and how likely we are to introduce bugs. Hopefully, most of the numbers you collect with your fancy tool will help predict what your really care about. But tools can be fooled.
You can have 100% test coverage without asserting a single thing about your code. And you can have maintainable, bug free code with super-high cyclomatic complexity and not a single line of code comments.
A leading indicator is a term investors use for measurements that change before the economy changes. A company’s stock prices is an example of leading indicators.
On the other hand, the term lagging indicator is used for a measurement that change after the economic reality changes. A company’s reported earning is an example of a lagging indicator.
Leading indicators, like stock prices and code coverage are useful because you can get hold of them early. However, they are not the real thing we’re after. The real thing we’re after is often a lagging indicator, like reported earnings or code maintainability.
Use leading indicators on your project to identify trouble areas early. But don’t be religious about them. Use lagging indicators to prove that you’ve met your commitment to quality. If your commitment to quality is reduced to code coverage, cyclomatic complexity or compiler warnings, you’re no better than the pointy-haired-boss counting lines of code.