It is said that you can’t manage what you can’t measure. Now, I don’t believe it’s imperative to quantify every aspect of every project. Nonetheless, coming from a scientific background, I respect the insights that thoughtfully gathered and analyzed data can provide. The right time to set up your metrics program is during project initiation so you can establish a measurement mindset and infrastructure at the outset. It’s much harder to reconstruct data from the early parts of the project if you don’t begin measurement until later on.

Chapter 12, presents a brief overview of software measurement. It describes why measurement is important, what you should measure, and some ways to create a measurement culture in your organization. I propose a number of metrics that are appropriate for individuals, development teams, and software organizations, along with several tips for making your metrics program succeed. Small or rapidly moving (such as agile) projects will likely select just a subset of these potential metrics. Regardless of the size of your project, though, you should think about choosing appropriate measures in the following basic dimensions: product size, time, work effort, cost, quality, and project status.

But software measurement is hard! There are many ways a nascent metrics program can go wrong. Chapter 13 describes ten "Metrics Traps to Avoid," conditions that can threaten the success of a measurement activity. For each trap I name several symptoms that could indicate you are already caught in this trap or that it might pose a looming threat. I also propose several possible strategies that can help you avoid the trap or extricate yourself if you’re already caught. Keep your eyes open for these traps if you want to make your software measurement program pay off.