Software development metrics that matter

Jim Bird has a post discussing software metrics (the good, the bad, the ugly). He advocates doing what makes sense for your organization:

“Only measure things to identify potential problems and negative trends, strong points and weak points in the code and your development process. If you want to set goals for the team to improve speed or cost of quality, let them decide what to measure and how to do it. And measure whatever you need to build a business case – to prove to others that the team is moving forward and doing a good job, or to make a case for change. Make metrics work for the team. You can do all of this without adding much to the cost of development, and without being evil.”

My perspective on metrics is as follows:
1. You can’t know how you are doing unless you collect some data and analyze it.
2. Only collect data on things you are interested in or want to doing something about.
3. If you aren’t going to do anything with the data, don’t collect it. (Do I care about the data? If no, then don’t collect it.)

Links:

• Software Reflections – Software Development Metrics that Matter