Chapter 13. Metrics Traps to Avoid[14]
Note
I was explaining our organization-wide software metrics program to a new manager. She said, "This is great. We can use the metrics program to drive the desired behaviors." This is not what metrics programs are for. You should use your software process improvement program to drive the desired behaviors and use the metrics program to determine the impact of those changed behaviors.
As software development gradually evolves from art toward engineering, more and more developers appreciate the importance of measuring various aspects of the work they do. Software metrics can help you understand and improve your work, but implementing a metrics program is a challenge. Both the technical and the human aspects of software measurement can be difficult to manage.
According to metrics guru Howard Rubin, up to 80 percent of software metrics initiatives fail within two years. This chapter presents 10 traps that can sabotage the unsuspecting metrics practitioner. I describe several symptoms of each trap, along with some possible solutions. Being aware of these common risks helps you chart a course toward effective measurement of your software development activities.
As with most improvement initiatives, management commitment is essential for a metrics effort to succeed. The most obvious symptom that commitment is lacking is when your management actively opposes measurement. More frequently, management claims to support measurement and effort is devoted to designing a program, but practitioners do not collect data because management hasn’t explicitly made it a requirement.
Another clue that managers aren’t fully committed is that they charter a metrics program and planning team, but then they don’t assist with deploying the program into practice. Managers who are not committed to software measurement won’t use the available data to help them do a better job, and they won’t share the data trends with the rest of the group.
To persuade managers of the value of software measurement, educate them! Tie the metrics program to the managers’ business goals, so they see that having good data available is the only way to tell if the software organization is becoming more effective. You need their input to help design the metrics program so it will meet their needs.
If you can’t obtain commitment from senior management, turn your attention to the project and individual practitioner levels. There are many valuable metrics that developers and project teams can use to understand and improve their work. Focus your energy at those who are willing to try. As with any improvement initiative, grass roots efforts can be effective locally. You can use positive results to encourage a broader level of awareness and commitment.
[14] This chapter was originally published in Software Development, 1997, 5(10): 49-56. It is reprinted here, with modifications, with permission of CMP Media Inc.