Pointy-Haired Extreme Programming

I'm a metrics nerd. I've turned all the projects in our company into number-production machines. In relatively sane ways, I must say. We're able to generate numbers as part of our automatic build processes, rather than chew up people's time in any big way.

And there's some evil there: my boss now regularly reports our "lines of code" velocity (726 lines per day!) to one of our major clients. The number is not meaningful without context, dammit!

David Rico says that there are twelve categories of project metrics:

1. Duration
2. Effort (person months, etc.)
3. Size (lines of code, function point count, weighted methods, etc.)
4. Productivity (size units divided by effort)
5. Design (lots and lots of metrics)
6. Quality (defect density, defect removal rate, etc).
7. Cost
8. Change
9. Customer Satisfaction
10. Performance
11. Return on investment
12. Reuse

According to Rico, the order of that list is also the order in which those metrics are cited. There are 3 major published formulas for calculating return on investment, and ROI tends to be cited less then 1% of the time. Now, I'm not a business person, but I would'a thought that ROI is one of the major metrics that one could use to determine if a project makes any sense.

Before I started my most recent foray into metrics, I didn't realize that there were a bunch of really interesting design metrics. I've always felt that I could look at a sample of code and declare it "good" or "bad" code. I've always wondered how to make that objective, however. Turns out that there are a lot of design metrics -- everything from how complicated a subroutine or method is to how many collaborators an object-oriented class has. (I think part of my blindness with respect to these metrics is that they don't neatly map on to "good" or "bad" -- good judgement is still required).

One metric that seems to fit uncomfortably in Rico's break-down is Halstead's Maintainability Index. It's a measure used to manage an application's maintenance cost in an organization (and necessarily measures design complexity as well). To use the metric, you have to also use Halstead's Complexity metric which is so abstract and theoretical that I've never seen it used in real life.

I keep trying to tune these metrics for the Java language -- most people who use metrics skip over so many details that it's hard to apply them to real languages. I keep thinking about writing a book, Pointy-Haired Extreme Programming, 'cause I'm sure that caring about metrics means that I've finally become a pointy-haired boss.