Preface

Every published software development process includes recommended metrics to use with that process. So why would anyone bother to write a book like this one? Is there any use for this book?

Well, have you ever discovered a software-delivery issue very late in the game, when it was too late to deal with the issue effectively? Have you ever believed you were tracking the right information to stay ahead of delivery issues, but surprises still came up? You’re not alone. From the earliest days of digital computers to the present day, people have been looking for reliable ways to detect potential delivery issues early enough to act on them. People still have difficulty understanding what to measure and what to do with the numbers they collect.

In my consulting work, at conferences and user group meetings, in online discussions, and in reading published material on the subject of software metrics, I often encounter people who are frustrated with the challenges of measuring software development and delivery work. They measure more and more things and generate more and more charts and graphs, and yet surprises still occur. Over the past 10 years or so, I’ve noticed a common denominator in these cases: people aren’t measuring what is really happening in their organizations; they’re measuring what they think is happening, or what they believe should be happening based on the labels and buzzwords people use to describe their process.