‘QSM2’ Category Archives

14
Oct

The Zeroth Law of Unreliability

by Tony in QSM2

“If a quality, like reliability, is not clearly specified, you can deliver the project earlier, if you interpret the quality requirements as “whatever it happens to be when the deadline arrives.” This, coupled with an innocent “Oh! You wanted more than two minutes between failures!” after the first complaints arrive, will solve the deadline problem initially. You are of course prepared to discuss a new schedule and project for enhancing quality to the required levels, not clarified for the first time”

– Tom Gilb

I like to quote Tom Gilb’s observations about what he calls “Weinberg’s Zeroth Law of Unreliability.” It represents the only time I can remember winning an argument with Tom. After he had published his “Gilb’s Laws of Unreliability”, I commented that he had left out the most important one of all, the Zeroth Law:

If a system doesn’t have to be reliable, it can meet any other objective

He argued that nobody could be so stupid as to not know that law, but a year later he admitted that most of his clients didn’t seem to know it at all. Moreover, they were desperately trying to remain ignorant of the law, and to keep their customers ignorant so they could use the escape hatch that Tom describes in the quotation above.

– Jerry Weinberg, Quality Software Management Vol 2, Chapter 19

13
Oct

Software Reviews as Training

by Tony in QSM2

In addition to all the other benefits, reviews teach while testing. Review participants learn about a number of things that are important to their development as software engineering professionals. First and most obvious, they learn about technical issues. They learn about various languages, tools and techniques. Learning in reviews is much cheaper than learning in formal classes, and is also more immediately relevant to the task at hand.

Participants also learn the specific product under review, which provides a much more secure base for project completion. If someone leaves or is needed in another task, anyone who has reviewed the project has a heard start on taking over.

They also learn about reviewing. Reviews are usually rather clumsy at first, but even without outside help, reviewers soon learn to do a much more efficient and effective job.

Less obviously, review participants learn about themselves. They learn just how good they are compared to others. This learning takes place without anyone being insulted or embarrassed, but helps people know what they can handle and what they cannot, as yet.

Participants also learn how much they have to learn, and what that is specifically. People who participate in reviews not only learn more effectively than those who participate in classes, they also make better use of those classes they do take, because they know what they need to know.

Finally, review participants learn about others in the review. They learn who is working on what, which develops a project consciousness and improves the efficiency of the informal communication system. They also learn who knows how to do what, so that when they have a future problem, they more quickly reach the person who can help them solve it.

Thus, although the review seems to be directed at the product, its major effect in the long run is on the process.

– Jerry Weinberg, Quality Software Management Vol 2, Chapter 18

12
Oct

Communicating About Plans and Progress

by Tony in QSM2

People need to communicate. Even when there is no task to be done, they communicate for the simple pleasure of being in touch with others. The worst punishment in prison is solitary confinement, and prisoners always find ways to communicate with others when they are placed in solitary, even if they have to tap messages through walls, one bit at a time. In software organizations, managers are sometimes horrified by the amount of communication that takes place. They may come to believe that their project is late because people are spending too much time communicating, rather than doing “real work”. Armed with this false belief, they erect barriers to communication, but thankfully these barriers never work perfectly. People manage to get the information they need, but at a much slower rate – so the project actually becomes even later.

– Jerry Weinberg, Quality Software Management Vol 2, Chapter 17

11
Oct

When Should Measurement Start?

by Tony in QSM2

Clients often ask me, “When is the best time to start measuring software?” By asking that question, they reveal that they don’t understand the basics of measurement. The time to start measuring is before you do anything else.

Physicists don’t design experiments, build apparatus, and then ask themselves, “Oh, by the way, what should be measure?” But many software engineering managers think they can do just that. They start some huge task without a thought to measurement, then call the measurement specialist when things start to go wrong. By then, usually, it’s too late to do much good.

– Jerry Weinberg, Quality Software Management Vol 2, Chapter 16

10
Oct

Dealing with Swarms of Failures

by Tony in QSM2

Brooks’s image of the tar pit has inspired, or terrorized, a generation of software engineering managers. It’s a grand image, but perhaps too grand for the struggles of today’s manager. For most managers in Variable (Pattern 1) and especially Routine (Pattern 2) organizations, a more useful image would be this: You are in the middle of a lake, rowing a boat with several slow, steady leaks. You want to fix the leaks, but are being attacked by a million mid-summer Minnesota mosquitoes. Observing and preventing failures (fixing the leaks) is a nice theory, but you are too busy chasing yesterday’s failures (swatting the mosquitoes) to do anything about it.

To do something about those mosquitoes, you first need to make some reasonable measurements telling just where they’re coming from, how many there are, and how fast you’re disposing of them with your current swatting efforts. If you could get some perspective on the situation (that is, get into the context position), you might see some way out of your plight. Of course, that’s easy to say, but it’s hard to be the congruent observer when mosquitoes are flying up your nose, stinging your ears, and crashing into your eyes.

Steering (Pattern 3) organizations rely on congruent observers. Steering managers can do so because they are effective in dealing with failures when there aren’t very many of them. Extending our story, Steering managers know enough to heard for shore after the first three bites.

Anticipating (Pattern 4) organizations keep their perspective by setting up automatic systems of observation. They operate from the outside observer position no matter what the crisis is. It’s as if the boat has an instrument that detects mosquito-free areas of the lake and steers the boat there.

– Jerry Weinberg, Quality Software Management Vol 2, Chapter 15

9
Oct

Management of the Future

by Tony in QSM2

Management of the future has an irresistible appeal for managers who cannot cope effectively with the present. Unfortunately, when the organization is in crisis, it’s not the time to leave town for a scientific conference on measurement, or to hide in the office devising long-range metric schemes. Some managers, of course, become so panicked in a crisis that they are unable to take an observer position. They ignore their own feelings, they don’t notice what’s happening to others, and they certainly have no connection with the overall situation.

– Jerry Weinberg, Quality Software Management Vol 2, Chapter 14

8
Oct

The Coping Is Everything

by Tony in QSM2

In analyzing what I see and hear in an organization, I try to avoid becoming ensnarled in the organization’s own definition of the problem. After all, if they understood the problem, they probably would have solved it already. I’m guided instead by Virginia Satir’s dictum:

The problem is nothing. The coping with the problem is everything.

I apply this dictum by looking for signs of incongruent coping. Incongruent coping strongly indicates a quality crisis because of the following dynamic:

  • Underlying every observed behaviour in a quality crisis is the quality problem
  • Because the quality problem is a systems problem, simple-minded solutions like adding large numbers of people will merely make the problem worse.
  • Long before we are consciously aware of the growth of a crisis, we are emotionally aware of it through the increasing stresses we feel.
  • Under emotional stress, we do not use our full intellectual power and instead resort to incongruent coping strategies to defend ourselves.
  • By observing these incongruent coping strategies, we can determine the scope and depth of the quality crisis. Coping strategies also direct us to what are likely to be the most effective interventions, based on what people are ignoring.

– Jerry Weinberg, Quality Software Management Vol 2, Chapter 13

7
Oct

Meta-Measurement

by Tony in QSM2

When an organization is out of control – when it is in a quality crisis – the measurement system is one of the first things to break down. Unfortunately, this deprives the people in the organization of the very information they need to figure out what’s happening; they don’t know how many problems they’re experiencing, let along the specific nature of the problem.

This could make the failure hard to detect if there weren’t meta measurement: the measurement of the measurement system. The fact that we have models like the Satir Interaction Model indicates that we can observe ourselves measuring, and measure how well we’re doing.

When we do understand the concept of meta-measurement, we can use the very lack of awareness of people in the organization as the surest way to observe a control system failure. During a quality crisis, people don’t know what’s really happening to them, although they’ll usually agree they are overloaded. If asked what they are doing with all their time, however, they are unable to give an accurate accounting.

– Jerry Weinberg, Quality Software Management Vol 2, Chapter 12

6
Oct

Precision Listening

by Tony in QSM2

Software is a precise business. When imprecision creeps into software work, failure and crisis cannot be far behind. One of the causes of imprecision is faulty reasoning by people who can’t hear themselves speaking. By learning to listen with precision, both to themselves and to others, peoples can observe many foolish acts, which contribute to the general foolishness of the organization’s culture.

To catch certain problems before they get out of hand, you can learn some general listening techniques. No other observation skill may be more important to software engineering than precision listening.

Improving your ability to hear what people are really saying can improve interpersonal effectiveness, requirements work, analysis, design, and consultation, as well as reviews of all sorts of technical work.

– Jerry Weinberg, Quality Software Management Vol 2, Chapter 11

5
Oct

Measuring Failures Before They Happen

by Tony in QSM2

Over my four decades in the information systems business, there have been many unsolved mysteries. For instance, why don’t we do what we know how to do? Or, why don’t we learn from our mistakes? But the one mystery that beats all the others, is why don’t we learn from the mistakes of others?

In order to prevent failures, we must observe the conditions that generate them. In searching out conditions that breed failures, I find it useful to consider that failures may come from the following eight F’s: frailty, folly, fatuousness, fun, fanaticism, failure, and fate.

Frailty means that people aren’t perfect. It is failing to do what you intended to do. Folly is doing what you intended, but intending the wrong thing … Fatuousness is being incapable of learning. Fatuous people do stupid things, and continue to do them, time after time … Nobody can predict what somebody else will consider fun, which is why fun is the most dangerous of all sources of failure … I will confess to a little fraud of my own. I have often used the (very real but minimal potential) threat of fraud by their employees to motivate managers to introduce systematic technical reviews, after failing to motivate them using the (very real and significant) threat of failure, folly, fatuousness or fun … Fanaticism, like fraud, is a way of getting management’s attention … Failure attributed to hardware may actually be caused by human error. These are really system failures … Fate is what most bad managers think is happening to them. It isn’t. When you hear a manager talking about “bad luck”, substitute the word “manager” for “luck”. As they say in the Army, There are no bad soldiers, only bad officers.

– Jerry Weinberg, Quality Software Management Vol 2, Chapter 10