In an article in the October edition of the FTP Webzine "Upside" Peter Varhol laments the trend toward per-developer metrics in the software development process. "Individual developer data is stored and available to be manipulated in less than honorable ways," he says, "and there are people in enterprises who know how to take advantage of such information for their own purposes."

Yes Peter, those people are called "managers" and their purposes are called "management." It's what they are supposed to do.

It's high time this industry grew up and, I'm afraid, growing up means opening up and letting managers see what developers are up to on a day-to-day basis. Earlier in his piece Varhol talks about the "bubble world" that developers have created for themselves by encouraging the view that software development is mysterious, highly complex, and technical.

Peter Varhol isn't the only person who seems change-averse in this respect. Other industry commentators have weighed in on the issue too. Linda Westfall is president of The Westfall Team, a consultancy that specializes in software metrics and software quality engineering training. "Don't measure individuals" she says in her 2005 paper on software metrics. "The state-of-the-art in software metrics is just not up to this yet." To be fair, she goes on to explain that what she's really talking about is individual productivity metrics measured in "lines of code per hour." True, that wouldn't seem to be a useful metric. But that doesn't invalidate the idea of looking at any metrics on a per-developer basis.

Sam Guckenheimer of Microsoft, in his book Software Engineering with Microsoft Visual Studio Team System, says: "Using metrics to evaluate individual performance is horribly counterproductive."

Joel Spolsky says, "FogBUGZ does not provide individual performance metrics for people."

So what's the deal? Why is everyone so against the idea of measuring the performance of individual developers? After all, in just about any other industry, you'll find per-individual metrics being applied without so much as a second thought.

Take sales for example. Culturally, you're unlikely to find any two groups in a company more diverse than sales and software development. But actually, these two departments have more in common than you might think. Both work in teams, but are highly dependent on the performance and contribution of individual members. In fact, oftentimes, the contributions of one or two "superstars" overshadow the contributions of everyone else put together. Both work for extended periods of time to deliver an outcome. And both are notoriously difficult to manage!

But there's one significant difference between these two groups. Sales teams, especially inside sales teams, have clear targets, not just for the outcome (dollars and cents) but also for their behavior on a day-to-day basis. I'll always remember one of the most successful sales managers I've ever known early in my career telling me the secret to her success, "Manage behavior; reward results." In the case of the inside sales team, the way we manage behavior is by looking at call metrics: the number of dials, total talk time, average call duration, etc. These are measures of the desired behavior of the team.

So, what's the desired behavior of the development team and what metrics can we put in place to measure it?

Well, Linda Westfall is right about one thing: we don't simply want to measure lines of code per hour. That's not a measure of productivity; it simply encourages verbosity! But perhaps we do want to measure compliance to coding standards. We might also want to measure unit test coverage and density, code complexity, reuse effectiveness, and defect rates.

The important thing is that we should think carefully about what behavior we want to encourage and then put mechanisms in place to capture the metrics to track our progress. But here's an important and rather subtle distinction between different types of metrics. Often, the thing that makes metrics, especially per-developer metrics, seem bad to so many people is that they when they think about metrics, they're thinking about prescriptive metrics. Prescriptive metrics carry with them a target level of achievement that defines success. The problem with prescriptive metrics is that they encourage slavish devotion to achievement of just that metric, sometimes at the cost of rational thought.

Joel Spolsky again: "As soon as you start measuring people and compensating people based on things like this, they are going to start optimizing their behavior to optimize these numbers, and not in the way you intended."

Coming back to our sales team example, if you just set a target for total talk time, without measuring the number of key contacts that the salesperson talks to, you encourage the wrong type of behavior - talking at length with someone who's never going to buy anything, for example.

The same thing applies in the software development world. It's generally accepted that 100% code coverage for unit tests isn't a good objective. Not only is it potentially time-consuming to squeeze the last few percentage points of coverage out of an application, but this is also the sort of thing that could really encourage the wrong behavior. Exception handlers are usually the hardest parts of the application to unit test. So what's the easiest way to increase your coverage percentage? Get rid of your exception handlers! That way you don't have to figure out how to test them.

Contrast that approach with the concept of descriptive metrics. As the name suggests, these are metrics that we just report, without any set notion of what's a "good" number in absolute terms.

To pick up the sales team example again the number of calls per day and total call time are descriptive metrics. We don't reward the team based on these metrics; we've already seen how that can lead to counterproductive behavior. However, if we observe a significant drop in sales by an individual then these metrics can provide a clue to the cause of the problem. Similarly, if a developer has consistently higher bug rates than his or her colleagues and lower unit test coverage then it's clear what action needs to be taken to bring that developer up to standard.

Here's the thing. This software development industry of ours is still pretty young. We're still figuring some of this stuff out. Blindly trying to apply manufacturing-style metrics to the software development process won't work. They are two different processes, and should be treated as such. But that doesn't mean we shouldn't be striving to apply some metrics and working hard to figure out what the metrics are and how to manage them.

So, to Mr. Varhol's target audience I say fear not. Embrace change. Don't stick your head in the sand and say metrics are a bad thing. Let's work together to figure out what we can measure, and how we can use those things to manage ourselves better. After all, our customers deserve better.