Development Metrics

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.



  1. A developer’s prodiuctivity is a bit too complex thing to be measured in terms of lines of code, number of unit test cases, or such artificial quantities.
    Along with the customer valued functionality, feedback provided by the immediate superior of the developer can be vital. Consistent feedback from a number of bosses becomes a clear indication of developer’s productivity.
    Looking forward to more of your writtings.

  2. I Count the No of file (Data and Device) fields, thwn get the no of hours spent on a function. Divide the Hours by No of Fields to give a co-efficient. I have different co-efficients for each program type (Screen, Batch, Report) Every time i write a particular kind kind of program i add the co-efficient to a total and get an average co-efficient for that program type. It gives a good estimate of development time to within +/- 10%.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s