Should You Manage by Metrics?

March 7, 2009

Metrics are a source of debate among many in the software development world. Personally, I feel that metrics are useful, but they need to be used properly.

An inappropriate use would be to measure a programmer’s job performance. For example, if you use lines of code as a primary measure a programmer’s job performance, you’ll get lines of code, in spades. I wrote about this problem in my blog post: Does a Software Productivity Metric Exist?

Plenty of others have written about this and and other common metrics as being a lousy measures of productivity as well. Here’s a couple of links if you are interested:

CannotMeasureProdctivity by Martin Fowler.

The Productivity Metric by James Shore.

What should metrics be used for? They should be used for comparison purposes to help teams and individuals improve, comparing yourself against the industry norm. For example, if your defect rates per thousand lines of code are above the norm, it may suggest that you need to spend more time on analysis and design before coding.

They are also helpful for planning purposes. A very useful blog post on this topic is one of Jeff Atwood’s Coding Horror posts, Diseconomies of Scale and Lines of Code. In it, Jeff notes that the lines of code metric is useful for determining a project size.

Jeff also cites my favorite software development author Steve McConnell, who points out that there is a non-linear relationship between a project size and overall productivity, something to be considered when planning projects and comparing yourself to others in the industry. To quote directly: “[Using software industry productivity averages], the 10,000 LOC system would require 13.5 staff months. If effort increased linearly, a 100,000 LOC system would require 135 staff months. But it actually requires 170 staff months.”

Simply stated, a metric is a gauge, measuring some key aspect that is important to your overall understanding of a larger picture that you are managing. If you want to improve the reading of the gauge, don't starting asking people to deliver more of what is displayed on the gauge! Examine what drives the reading and turn those knobs instead. This is why demanding “more lines of code” from programmers does not actually increase productivity.

Furthermore, metrics should be confined to measures that help you understand and to improve your results. Don't get metric-happy and measure everything that you can think of. Focus on the areas of critical importance and the key measurements that you need to understand how you are doing.

In the end, measuring informs you, but managing is all about understanding what the work is and why certain practices will increase your odds of success. The real need is to manage the business, to manage people, and to manage projects. Reducing management to any one metric is an oversimplification that will only create Dilbert-like scenarios.

My post Six Keys to Successful and Productive Software Delivery discusses the areas that I consider important to measure and manage.

Since I've touched on management in this post, I'll commit to examining my own role as a manager in my next post. As I’ve mentioned, we’ve adopted Agile development at my company, so I’ll examine my role with respect to Agile. Fair warning: I’ll work at refuting the notion that there isn’t a need for managers with empowered, self-directed teams!