I am commonly asked "What metrics do you use to measure developer productivity?". There are a of common metrics that people use such as lines of code written (*shudder*) to number of unit tests written. Both of these suffer from the same root cause: they are measuring something artificial. The number of lines of code that I produce is completely artificial. I can have a style that separates declaring a variable from setting the default value. This makes me "twice" as productive as someone that sets the value in the declaration (the latter of which may be more maintainable code). The number of unit tests that I write is also completely artificial. I can write seven unit tests for a form with seven fields or I can write a single unit test that tests all seven fields at once. (I'm obviously using contrived examples to elucidate a point.)

So what is a non-artificial unit that one can measure for developer productivity? David J. Anderson calls it "customer valued functionality". If your organization is already up to speed on an agile development methodology (FDD obviously being the best fit) then you are likely already defining units in terms of something that the customer values. You measure the rate at which your developers produce and the customer accepts this customer valued functionality.

(This is an interesting article on metrics and agility.)

This notion of "non-artificial" is especially poignant for me in the recent months. I have been spending my time working on an approach to enterprise security that integrates decision support with a business process centric view. Currently most security decisions are made based on particular threats and vulnerabilities along with best practices. What's interesting about this is that measuring a company's risk from the standpoint of threats and vulnerabilities is akin to measuring developer productivity by measuring the number of lines of code that they produce. Instead of measuring something "artificial", risk should be understood from the standpoint of "how will this impact my business". From an IT person's view the answer is always death and destruction and the business owners just react to that. But the real question for the business owners should be: what is your tolerance to this particular "bad thing" and what impact will it have on your business? I'll be talking about this more in the future.

I have talked a number of times in the past about the CMMI. David J. Anderson has written the paper Stretching Agile to fit CMMI Level 3. It's an interesting read. For more information on this you can check out MSF for CMMI Process Improvement as well as a webcast by Mr. Anderson.