Responding to Significant Software Events

Responding to Significant Software Events

by

Gerald M. Weinberg

SMASHWORDS EDITION

PUBLISHED BY:

Gerald M. Weinberg on Smashwords

Responding to Significant Software Events

Copyright © 2011 by Gerald M. Weinberg

All rights reserved. Without limiting the rights under copyright reserved above, no part of this publication may be reproduced, stored in or introduced into a retrieval system, or transmitted, in any form, or by any means (electronic, mechanical, photocopying, recording, or otherwise) without the prior written permission of both the copyright owner and the above publisher of this book.

Smashwords Edition License Notes

This ebook is licensed for your personal enjoyment only. This ebook may not be re-sold or given away to other people. If you would like to share this book with another person, please purchase an additional copy for each person you share it with. If you're reading this book and did not purchase it, or it was not purchased for your use only, then you should return to Smashwords.com and purchase your own copy. Thank you for respecting the author's work.

Contents

Preface

Acknowledgements

Part III. Significance

Chapter 1: Measuring Emotional Significance

Chapter 2: Measuring Failures Before They Happen

Chapter 3: Precision Listening

Part IV: Response

Chapter 4: Translating Observation Into Action

Chapter 5: Observations from the Empathic Position

Chapter 6: Dealing With Swarms of Failures

Part V: Zeroth-Order Measurement

Chapter 7: Projects Composed of Measurable Tasks

Chapter 8: Communicating About Plans and Progress

Chapter 9: Reviews as Measurement Tools

Chapter 10: Requirements: The Foundation of Measurement

Chapter 11: The Wayfinder

Appendix A: The Diagram of Effects

Appendix B: The Software Engineering Cultural Patterns

Appendix C. The Satir Interaction Model

Appendix D. Control Models

Appendix E. The Three Observer Positions

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 five 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 several smaller projects, each one addressing part of one of these three fundamental abilities. Volume I, Systems Thinking dealt with the first ability—the ability to understand complex situations. Based on feedback from my readers that the book was too long for an eBook, I split it into two volumes, How Software Is Built and Why Software Gets in Trouble, making a few updates in the process.

For the same reason, I've split the second original volume—First-Order Measurement—into two more accessible volumes. First, was the volume—How to Observe Software Systems—which treats the ability to observe what's happening and provide meanings to those observations. This volume (fourth in the eBook series)—Responding to Significant Software Events—concerns how to understand the significance of observations, and how to respond appropriately to the significant events.

I spent much time anguishing over the correct title for the original volume before settling on First-Order Measurement. It wasn't a bad title, but the word measurement confused some readers. The term first-order confused others. For these reasons, and better to distinguish the editions, I've omitted both terms from the present titles in favor of more easily understood phrases.

Even so, this volume in particular certainly concerns measurement, so to avoid further confusion, I feel 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 used to tune the 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.

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. These Software Management books are 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—Responding to Significant Software Events—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 these volumes. In fact, if your organization meets these criteria, I would be delighted to refund whatever you paid for these books 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—to help your organization consistently produce the quality software you and your customers desire.

Acknowledgements

I'd like to acknowledge the important contributions of the following people to the improvement of this book, through reviews, discussions, demonstrations, experiments, and examples: Jinny Batterson, Jim Batterson, Mike Dedolph, Peter deJager, Tom DeMarco, Kevin Fjeldsted, John Freer, Phil Fuhrer, Dawn Guido, Capers Jones, Payson Hall, Jim Highsmith, Naomi Karten, Norm Kerth, Lynne Nix, Brian Nejmeh, Judy Noe, David Robinson, Wayne Strider, Linda Swirczek, Dani Weinberg, Ellie Williamson, Janice Wormington, Gus Zimmerman

Plus, the Change Artists and others in my client organizations, as well as numerous participants in the Problem Solving Leadership Seminars, the Organizational Change Shop, the Quality Software Management seminars, and other educational experiences.

In this book, I'll disguise all people and clients from whom I've obtained confidential information.

Part III. Significance

Man is the only animal that blushes. Or needs to. - Mark Twain

The third step in observation according to the Satir Interaction Model is Significance. Significance is the meaning of the meaning—not in a cosmic significance sense, but in the sense of importance to one or more of us. Therefore, the keyword for the Significance step is relevance: providing a filter to reduce the complexity of the real world to a size our brains can handle.

Chapter 1: Measuring Emotional Significance

It's not bad to have aggressive or hostile thoughts and feelings toward others. When you acknowledge these feelings, you no longer have to pretend to be that which you are not. You can learn to accept these moods. What is bad, however, is letting them dictate your nature. When you unleash your aggression or hostility on another person, it inspires aggression and hostility in return. The result then is conflict, which all true martial artists try to avoid. Anger doesn't demand action. When you act in anger, you lose self-control. - Jim Lau, as quoted by Joe Hyams

Now is the time to move into more dangerous territory. I'm a bit afraid of losing some of my readers when I write about the f-word: FEELINGS. On the other hand, I believe I'm perfectly justified in being afraid, because I know the danger is real. Whenever I speak about quality software management to a large audience, about 10% of the audience tunes out—and one or two actually walk out—when I reach the third stage of Satir's Interaction Model. Evidently, these people have a strong emotional reaction about the subject of emotional reaction.

So, this chapter is a test for you. Notice what you take in. Notice what meaning you make of it. And then notice your emotional reaction. You may find yourself feeling aggressive or hostile, and that's okay with me as long as you don't act on it. (Emails are okay, but no ticking packages, please.) Or, you may be afraid, but that's okay, too, because I just admitted that I'm also afraid. You may be delighted—not all emotions are negative—in which case I'll be delighted along with you (and emails are still okay). You may even be bored or indifferent, which are some of the most common emotional reactions to my long-winded lectures—and the ones I fear the most.

But whatever it is, you'll have some emotional reaction, because that's the way we human beings respond to the meaning we ascribe to the data we take in. So let's turn to the next stage of the Satir Interaction Model: the extraction of significance (Figure 1-1).

Figure 1-1. The third stage of the Satir Interaction Model is extracting significance.

1.1 A Model of Extracting Significance

Let's examine how I determine the significance of a message you SENT. The intake and interpretation of most inputs require only a tiny fraction of a second of my internal processing. In this short time, my mind is already two large steps removed from what you SENT. As a result of that processing, I am now focused on my own INTERPRETATION of what I RECEIVED, not what you SENT.

Moreover, this particular interpretation is only one of hundreds of possible interpretations, yet I will use that one interpretation to start the next part of the process—deciding what significance your behavior (that is, my interpretation of your behavior) holds for me.

1.1.1 Some thoughts about feelings

At this point in the interaction, feelings start to come into play. At this point in the interaction, many of us begin to lose our way. If you cannot distinguish thoughts from feelings, you're never going to get very far as an observer, or as a manager. So let's take a few moments and try to be clear about the difference.

I can sensibly say, I think I have food poisoning, but not, I think I have a pain in my gut. Why the difference? The difference lies in the way I know each thing.

I know I have food poisoning because I have assembled a variety of facts—including the pain in my gut—and reasoned to the conclusion that the cause is food poisoning. I don't think I have a pain in my gut. I know I have the pain—because it's there. Because I can feel it directly.

My doctor may talk me out of the idea that I have food poisoning by presenting other evidence, such as an X-ray showing I have gall stones. But even with this new evidence and the new thoughts that derive from it, I still have the pain. She may distract me from noticing the pain, or suppress the pain with drugs, or mask the pain with fear of a gall bladder operation, but the pain doesn't disappear the way an erroneous thought can disappear once I've seen better reasoning.

Feelings—such as pain, well-being, hurt, joy, sadness, attraction, repulsion, indifference, nausea, humiliation, shame, embarrassment, boredom, curiosity, anger, excitement, liking, puzzlement, fear, and love, to name a few—all fit this same pattern. I know directly that I have a feeling. I don't arrive at it by a process of reasoning.

1.1.2 Thoughts can give rise to feelings, and vice versa

We mustn't be confused by the way people say, I think I'm in love, or I think I'm nauseated. This is simply a language problem. It would be more precise to drop the words I think and say, simply, I'm in love, or I'm nauseated, because thinking had nothing to do with it. It was a feeling.

Or perhaps I have a feeling but I don't know the name of that feeling. I think I'm falling in love (but I don't know if that's what this feeling is because I've never been in love before).

Don't misunderstand. Although I don't know I have a feeling by a process of reasoning, thoughts can give rise to feelings. If I think a project is going to be late, I might feel angry, happy, scared, confused, curious, or just about any feeling.

And then, in turn, the feeling could give rise to a thought. If I'm happy that your project is going to be late (perhaps because that will cover the fact that my own project is also late), I might think about making sure I don't help your project go faster. If I'm scared that your project is going to be late (perhaps because that will cause my own project to be late, too), I might think about offering you some of my resources.

We know that one thought can trigger another thought—this is the process called reasoning. What confuses us is that thoughts can trigger feelings and feelings can trigger thoughts—we don't have a name for this process. Yet this process characterizes the internal processing of the most confusing interactions.

1.1.3 The feeling response

Let's return to the interaction between you and me. It began when you said, Let's call the accounting department. I RECEIVED some, none, or all of it, then made my own INTERPRETATION (one of many possible interpretations).

I now react inside with a feeling about my INTERPRETATION. (Figure 1-2).

Figure 1-2. I have a feeling about my interpretation.

1.1.4 Feelings are arbitrary and mysterious, but real.

Suppose that my INTERPRETATION is

(INTERPRETATION1) You and I have disagreed before, so let's call in an outside authority to check what we've done.

My internal feeling response might pop up as:

(FEELING) I'm afraid because I think that you're trying to make me look bad to the boss.

This feeling is not something I arrive at rationally, and just how it does appear is one of the great mysteries of psychology. Once I've fixed on an interpretation (INTERPRETATION), the feeling just seems to appear before I know what's happening. Because feelings just happen doesn't mean, however, that anyone else would have the same feeling in the same situation. It merely means that my particular feeling seems to come without choice, to me.

At least I have the choice of being aware of my feeling, and differentiating it from my other feelings. It can help keep things straight if I know whether I'm angry or hurt or excited or scared. This will assist me in doing the right things with my observations.

You, in turn, will find it easier to interpret my response if you remember that I might get almost any feeling, regardless of what you intended by what you said. For example, you're likely to be totally mystified about why I was afraid in this context. You, yourself, might be angry that (you thought) someone was trying to make you look bad to the boss—or you might be sad. Or perhaps glad that there was finally going to be a showdown.

Even if you would have been afraid, you might have been afraid for a very different reason. For example, you might have been afraid because you're three months behind in your expense accounts, and you've been avoiding the accounting department until you find time to catch up. If you see that