Quality Software Management

(Quality Software Series)

Volume 2: First-Order Measurement

(translated into Japanese, Portuguese, Chinese)

– How To Observe Software Systems (Quality Software Series #3)

-Responding to Significant Software Events (Quality Software #4)

Sample and/or Buy either ebook through:

KINDLE

Barnes & Noble

Smashwords

Buy at Amazon.com

“Quality Software Management is a software starship that has gone where no-one has gone before; and if there is further to go, Weinberg is certainly not stopping us from going.” —Nicholas Zvegintzov. Software Management News

“What struck me as amazing as I read First-Order Measurement was not that so many software projects fail, but that so many manage to succeed. This book should be required reading for anyone who cares about project success.” —Naomi Karten

President, Karten Associates

“. . . delightful . . . peppered with the kind of quotations that software engineers love to tape on their managers’ doors in the middle of the night, in hopes of inspiring change for the better. . . . enlightening, practical, humorous, and enormously inspiring.” —Ed Yourdon American Programmer

“. . . brimming with simple techniques and examples of their application.”

—Roger D.H. Warburton

Computing Reviews

“The wealth of wisdom in this volume speaks directly to individuals who want to improve their own powers of observation—a prerequisite to successfully applying knowledge to improve software quality. . . . First-Order Measurement is a must for all sentient software line and project managers!” —Shel Siegel, Software Quality World

Become much more effective in working with others

http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=BOOK&ObjectId=127

by Derek Mahlitz

This book shows how to more precisely observe and measure the software development process and offers a model to break down the complex software process into a series of compact, simpler to understand steps. It also describes the minimum set of activities for any software organization to start a successful measurement activity, as well as the key factors to help organizations consistently produce the quality software they desire. The book is divided into four areas: Intake, Meaning, Significance, and Response.

This book focuses on an issue of huge importance to software managers: how to respond appropriately to people (clients, bosses, team members) in difficult, emotionally charged situations. The author uses simple but effective models to explain human behavior. He includes examples from the software engineering industry to put these models in contexts familiar to software developers. The models can help all software professionals to understand and deal with conflicts more effectively, using the insights gained from this book every day with software development teams, clients, employees, and personal interactions. As the author has pointed out, one of the main questions in software engineering is “Why do people so often do things wrong when they know how to do them right?” As this book shows, to do the right thing often requires that in a moment of confrontation, you must interact with all points of view, with the needs and fears and personalities of all parties to the issue. The insights, examples, and tools Weinberg provides here can help you become much more effective in working with others. I strongly recommend this book, and the rest of the set, to people who lead software projects and lead project managers themselves.

Reader Comments

I agree with everything the original reviewer said. I don’t see how anyone can consider themselves interested in software quality without having some of Gerald Weinberg’s books on their shelves (preferably well-thumbed). While I don’t always agree with everything that Weinberg says, he does force you to THINK. My only real quibble is that the title of the series limits the perceived coverage to software. In my opinion, the material in these books is applicable in any development activity…..- Keith Collyer

Real insights about software development process

Reviewer: A reader from Turin, Italy (Source: Amazon.com)

This book give good insights about the use of dynamic modelling applied to the software development process. Great to understand the real meaning of non linearity of human based processes and great to highlight how some easy macro indicator can give info about your software development process.

The book’s contribution to the software development process is of the same type of Senge’s Fifth Discipline for general management

Preface

“When you can measure what you are speaking about and can express it in numbers, you know something about it. But when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind.” – Lord Kelvin

In the four decades I’ve spent in the software business, I’ve learned that there are three fundamental abilities you need to do a quality job of managing software engineering:

1. the ability to understand complex situations so you can plan a project and then observe and act so as to keep the project going according to plan, or modify the plan

2. the ability to observe what’s happening and to understand the significance of your observations in terms of effective adaptive actions

3. the ability to act appropriately in difficult interpersonal situations, even though you may be confused, or angry, or so afraid you want to run away and hide.

All three abilities are essential for quality software management, but I didn’t want to write a large, imposing book. Therefore, like any quality manager of software, I decomposed the project into three smaller projects, each one addressing one of these three fundamental abilities. Volume 1, Systems Thinking deals with the first ability-the ability to understand complex situations. Volume 3, Congruent Action deals with the third ability-the ability to act appropriately even in the presence of strong feelings. (Since this preface was written, I decided to add a fourth volume, on how to make the changes suggested by the previous three volumes-Volume 4: Anticipating Change.) In this second volume-First-Order Measurement-I invite your attention to the ability to observe what’s happening and to understand the significance of your observations.

I spent much time anguishing over the correct title for this volume before settling on First-Order Measurement. For one thing, when a book is published with the word “measurement” in the title, the author seems obliged to quote Lord Kelvin. I have kept to that tradition, but now feel compelled to analyze what Lord Kelvin meant, and did not mean, by his oft-quoted statement.

When you can measure what you are speaking about, Kelvin said, you know something. If you are measuring just for the fun of knowing things, then it doesn’t much matter what you measure. But if you are trying to accomplish something, then arbitrary measurements are perhaps not what you need to know. Engineering is about accomplishing things, so engineering measurements are not arbitrary.

Lord Kelvin was a physicist. Although I wanted to work with computers since I was a boy, I was trained as a physicist because there was no computer training in my school days. Today I consider myself a software engineer, and though I still love physics, I distinguish between knowing in physics and knowing in engineering:

Physics knowing is understanding the universal laws of nature.

Engineering knowing is knowing how to do something.

I use the term “third-order” measurement for the kind of measurement that supports the physicist’s search for universal laws. An example of third-order measurement would be an experiment that tested the First Law of Thermodynamics that says, in effect, that it’s impossible to build a perpetual motion machine.

Engineers are not trying to know universal laws, but special laws relating to building specific things. Therefore, they are interested in what I call “first-order” and “second-order” measurement. An example of such measurement would be measurements to build and tune a high-efficiency machine.

The term “first-order measurement” is used in engineering to describe a measurement just adequate to the task of getting things built. First-order measurements are used in “back of the envelope” (or, in England, “back of the cigarette box”) calculations. They support the “rule of thumb” and the rough sketch, as well as the “quick and dirty” or “seat of the pants” estimate. These are the measurements that allow us to build a machine in the first place.

The term “second-order measurement” refers to the kind of refined measurement used to optimize systems-to make them cheaper or faster. These are the measurements that are used to tune a machine to its most efficient performance. If you examine the other software engineering books with “measurement” or “metrics” in their title, you will find that they primarily deal with second-order measurement, and in some cases, even third-order measurement.

Although second- and third-order measurements are essential to the development of the software engineering profession, they do not really address the day-to-day problems of the typical software engineering manager. Perhaps the following parable will clarify why I make this claim:

Mr. and Mrs. Tweedle had 15-year-old twins, Dum and Dee, who were just learning to drive a car. Dee had driven the family car ten times, and she had a perfect safety record. Dum had also driven the car ten times, but he had been involved in three wrecks. Mrs. Tweedle told Mr. Tweedle that he had to have a talk with the boy, before someone was killed.

Mr. Tweedle opened the conversation by reviewing the three accidents, then asked Dum, “What do you have to say for yourself?”

“Well, three accidents out of ten trips isn’t such a bad percentage.”

“I might agree with you,” said Mr. Tweedle, “but your sister, Dee, has also made ten trips without so much as a stone chip on the windshield.”

“That’s true,” said Dum, “but I get much better gas mileage than she does. And I don’t get mud on the tires.”

“Oh,” said Mr. Tweedle. “I hadn’t thought of those things. Well, just try to drive more carefully from now on, and keep up the good work on mileage and cleanliness. I’m going to have to talk to your sister about her driving habits.”

Even to those of us who have been bamboozled by our own teenagers, Mr. Tweedle sounds like an idiotic parent. But before you judge him too harshly, remember that the story is only a parable. And what is it a parable for? You may recognize the three out of ten figure from software engineering. It’s the fraction of large software projects that, among many of my clients, don’t ever get finished. Capers Jones, Tom DeMarco, and Tom Gilb have all confirmed to me that this 30% figure is consistent with their experience.

Suppose you were the manager of software development in an organization that had done ten projects, three of which had failed. The software engineering managers from those failed projects can show you precise measurements proving that they produced more lines of code per dollar and fewer failures per line of code than the other seven projects. Would you go to the other managers and talk to them about their managing habits? Of course not.

As John von Neumann said, “There’s no sense being precise about something when you don’t even know what you’re talking about.” But that’s exactly what many managers are doing when they involve their organization in measurement programs based exclusively on second-order measurement. Bill Silver, one of the gurus of software measurement, said,

“It’s sad, but true. Most software measurement programs fail.” (1)

Silver’s observation is confirmed by Capers Jones, whose experience is that 80% of software measurement programs are out of existence within two years. It’s also confirmed by my own clients, who fit his description of the first and foremost reason for failure:

“Few companies have a quality culture that provides a positive environment for measurement.”

Let me put it more bluntly. A company that wrecks three out of ten major software projects is not ready for second-order measurement. Even worse, if such a company attempts to install a measurement program based primarily on second-order measurement, they will do more harm than good, and probably wind up with a million-dollar measurement mess. This is not “a positive environment for measurement.”

The data on software quality cultures indicates that at the present time, only a small percentage of organizations have organizations that would support a second-order measurement program. (2) Quality Software Management is designed to help the managers in those organizations improve the quality of their management, so that in turn they may improve their organizations.

The purpose of this volume-First-Order Measurement-is to help those organizations reach a point where they can meaningfully consider the use of second-order, or even third-order, measurement. If you work in an organization that churns out software products on time, within budget, that please your customers and continue to please them over their useful life-and you do this at least 99% of the time-then you won’t need to read First-Order Measurement. In fact, if your organization meets these criteria, I would be delighted to refund whatever you paid for this book in exchange for lessons in quality management.

But if your organization doesn’t meet these criteria, then I hope to show you how to create “a positive environment for measurement,” to avoid the costly mistakes that have led to failure of so many measurement programs, and how to measure things simply and efficiently-things that will help your organization consistently produce the quality software you want.

1. Silver, Bill, “The RPM3 Software Measurement Paradigm,” Software Quality World 1991:3,2, 11-15.

2. Humphrey, Watts, D. H. Kitson, and T. C. Kasse, “The State of Software Engineering Practice: A Preliminary Report,” Tech. Report CMU/SEI-89-TR-1, Software Engineering Institute: Carnegie Mellon Univ., 1989.