Dave Nicolette - Software Development Metrics

For online information and ordering of this and other Manning books, please visit www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact

Special Sales Department Manning Publications Co. 20 Baldwin Road PO Box 761 Shelter Island, NY 11964 Email: orders@manning.com

2015 by Manning Publications Co. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps.

Recognizing the importance of preserving what has been written, it is Mannings policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15 percent recycled and processed without the use of elemental chlorine.

Manning Publications Co.20 Baldwin RoadPO Box 761Shelter Island, NY 11964

Development editor: Cynthia KaneTechnical development editor: Mark ElstonCopyeditor: Tiffany TaylorProofreader: Barbara MireckiTypesetter: Dottie MarsicoCover designer: Marija Tudor

ISBN 9781617291357

Printed in the United States of America

1 2 3 4 5 6 7 8 9 10 EBM 20 19 18 17 16 15

To Lourdes and Alejandro

It took several years to prepare this small book, and there were many occasions when I was strongly tempted to abandon the project. My wife Lourdes and my son Alejandro were consistently supportive. The fact this book was completed is due largely to their loving and steadfast encouragement.

Years back, I noticed that Dave Nicolettes blog had the same subtitle as mine, Effective Software Development. This contrasted subtly with what seemed to be the dominant interest at the time, efficient software development. I quickly found out that even when our opinions differed, our goals and values tended to be in close alignment, and the conversations were always enlightening.

Ive worked with a number of organizations, large and small, in a decade of being an independent software development consultant. This work has given me opportunity to observe these organizations in action. The ones that are most stuck are the ones that focus on efficiency.

Efficiency tends to squeeze the slack out and discourages taking time to wonder and explore. This single-mindedness eliminates the opportunity to learn. Learning is reduced to optimizing measures within the local neighborhood of the status quo, often to the detriment of valuable things less easily measured. Companies set up systems to gather this data efficiently, sometimes at the expense of veracity. If the metrics mania takes hold, they may have programmers take time from programming to collect more data, blindly sacrificing efficiency in real work on the altar of efficiency in measuring the work.

Ive seen other companies initiate a metrics program because ... well, because its the thing to do. It will improve their process, or enable them to manage scientifically, or attain some other vague goal. They generally try to measure as much as is convenient to capture. They often start with every metric that their toolset makes available, but they dont have a clear idea of what to do with the numbers they collect. In fact, Ive seen cases where nobody ever looked at the numbers. They just found collecting numbers reassuring, like a child playing with a teddy bear.

As they mature just a little, organizational metrics programs start to develop goals for their measurements. Ive seen obsession with efficiency accompanied with using metrics to ensure they are maximizing the productivity indicators that they can easily measure. Ive seen people collect measures to confirm what they already believe. Ive seen them overlook data that might invalidate beliefs or assumptions. Ive seen them ignore data they have, because its not in a form thats convenient to quantify. Ive seen them use metrics to set targets for managers and workers, falling victim to Goodharts Lawa metric used as a target ceases to function as a measurement.

There are so many ways that we can use metrics to lead ourselves astray. Its easy to depend on them to make our decisions for us, rather than use them to illuminate reality so we can make better decisions. The common problems with metrics programs make it tempting to do away with them.

Unfortunately, we can fool ourselves just as easily with anecdotes. Measuring things can be a great way to double-check our beliefs. Measurements can also uncover phenomena that we hadnt otherwise noticed.

So I had great interest when Dave told me he was working on a book about metrics. I knew it wouldnt be a run-of-the-mill, shortsighted book. And, indeed, it is not. Dave describes here how to use metrics to do our bidding, rather than to be our masters.

This is an opinionated book. Dave does not catalog all of the metrics he knows. He dwells on the ones he finds effective. With each of these, he not only tells us when its appropriate and how to use it well, but cautions us about how it can lead us astray if we use it clumsily. In addition, he cautions against a couple metrics that are not helpful for steering software development projects.

In this book, Dave concentrates on two goals of using metrics: steering a software development project to success, and improving the process of software development. He provides practical advice on how to meet these goals, advice grounded in years of experience. There are examples of using multiple metrics to derive insights into the development process, to stabilize the predictability of planning, and to report upwards in the management chain. This book will be a helpful guide to most project managers and team leads, and a real boon to those making a transition from a traditional serial development model to an agile one.

G EORGE D INWIDDIE

S OFTWARE D EVELOPMENT C ONSULTANT AND C OACH

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? Youre 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, Ive noticed a common denominator in these cases: people arent measuring what is really happening in their organizations; theyre 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.