Asymptotically Approaching Useful Developer Metrics
How do you measure the progress of a software project, or the programmers on that project? How would you prefer that it be done?
Everyone wants a way to dispassionately evaluate the productivity of a software development team. The boss wants to know at both a high-level (are these projects on-track? are we going over budget?) and in granular terms (which programmer creates the best quality code fast, and should I give her a raise before she asks for one?)
Developers, too, want a way to measure their personal and team's progress because we all do want to do the best job possible. The team wants to know where the problems are so they can be addressed, ideally before the boss notices on her bright shiny dashboard application. Plus, at a personal level, every IT worker yearns for a dispassionate metric to say, "This is how good you are, at least in comparison to your coworkers." Such a measurement at least suggests that, at employee review or promotion-time, the decisions might be made on merit rather than office politics, self-promotion or "social networking" (doesn't that sound better than sucking up? I thought so).
So far, so good. Everybody wants useful metrics. The only problem is, no one has ever developed a metric that is universally accepted as useful. The easiest one to make fun of—c'mon, let's all point and laugh—is "lines of code" (LOC), a measurement that inherently does not take into account the language in which the developer writes (some are wordier than others), nor the generally accepted assumption that better code is generally more concise (particularly with an eye to code re-use). And, since in any endeavor, you only "get" what you measure and reward, shops that pay attention primarily to LOC (if there are any, and I sincerely hope not) encourage flabby code with no especial attention to making it quality code.
Lots of other metrics have been tried, I believe, but as far as I know there's none everyone likes and accepts. In any programming team, everyone seems to know who's the "smart" member, who can crank out code that's ugly but works, who would never be considered a brilliant developer but is team-glue and an idea catalyst. All those roles are necessary. Are there any metrics that capture all that? Probably not, though as with all such things it's fine for us to approach perfection one attempt at a time.
But the stats are still necessary, at least at a managerial level, so that a CIO can say authoritatively, "We're on schedule to ship by the end of the year," or recognize that the performance testing team needs more help, or whatever. So there's a whole branch of Application Lifecycle Management that aims, in various ways, to help CIOs and AppDev managers with the essential skills of cat-herding. That's a good thing, mind you, especially when I am the user who is anxiously awaiting the release of a software project (like, say, updates to the Drupal code for the Advice & Opinion site... just to pick something out of the blue, you understand).
The thing is... I wonder whether the managers and developers are on the same page. Are the metrics that help CIOs make strategic decisions the same ones that help developers keep their projects on track? What statistics are useful... for either community? Do numbers and reports which help one community make decisions get in the way for the

