Product Development Metrics

I recently exchanged e-mails with Andreas Graae, CTO at one of the expansion stage software companies, Zmags (www.zmags.com), in our venture capital investment portfolio about the usefulness of a metric around software development.

I had posted a list of possible metrics and included “number of builds run per day”.

What’s the point?, he asked.

My response is the following:

• If a team is doing continuous integration to best practice, the developers should, in most situations, be doing multiple commits per day as they complete tasks and stories. So if the metric is very low, it may point to opportunity for improvement in identifying defects or other issues earlier in the sprint.
   
• Trying to measure the metric may point to the team not doing continuous integration, and asking for it may spur discussion around it, and again, lead to significant improvement.

That said, the metric may be completely useless for many teams (especially those that have been doing best practice in continuous integration for some time), and it is by no means a measurement of performance or a tool for motivating or managing the team.

It is an informational metric, not a motivational one (as described in Measuring and Managing Performance in Organizations by Robert Austin), and can be turned into a “bad metric“.

In the course of our e-mail exchange, this Chief Technology Officer also introduced me to this site: http://www.sonarsource.org/, which seems to have a great tool set of monitoring code “quality”.