‘QSM2’ Category Archives


The Subjective Impact Method

by Tony in QSM2

Every reporting method should start by asking the question, Who is the audience for this report? In other words, Who are the people whose values count in determining quality? The subjective impact method uses that audience’s criteria for evaluating something new. Don’t assume that you know the basic questions to ask unless you are part of the audience yourself. You must find out from your audience what those questions are and also who has believable answers. After you have discovered those things, you can then interview the right people with the right questions.

The first key idea of the subjective impact method is to interview using categories that your audience values. The second key idea here is to interview people whom your audience will believe. The next key idea is to ask this identified population direct questions about the value. Because the audience has said they will believe this group, you do not need to make a case. All you need to do is gather information.

— Jerry Weinberg, Quality Software Management Vol 2, Chapter 9


Confusing Cost and Value

by Tony in QSM2

To err is human; to combat error is software engineering. A great deal of software engineering research has been devoted to eliminating error early, which is all to the good. But no amount of effort will prevent errors from occurring at all; that would violate the two strongest sets of laws we know: laws of thermodynamics and laws of human nature. The Second Law of Thermodynamics says: To decrease entropy (increase information), you need to add energy.

In colloquial terms, this means: There’s no such thing as a free lunch.

In other words, you have to pay to get quality; and the higher quality you want, the more you have to pay. Crosby’s book title Quality is Free doesn’t mean you don’t have to pay for quality. Crosby means that you’ll be more than compensated for whatever you pay.

Crosby’s concept has great appeal for managers because of the First Law of Human Nature: People never want to believe the Second Law of Thermodynamics applies to themselves.

My job of working with software engineers would have been easier if Crosby had title the book Quality Pays – But Only If You Invest In It. Unfortunately paying a high price does not guarantee a fine lunch, just an expensive lunch. The investment in quality must be more than money and hard work. To produce quality consistently, managers must learn new ways of thinking. Simple linear thinking is not adequate to the task of combating the Second Law of Thermodynamics.

— Jerry Weinberg, Quality Software Management Vol 2, Chapter 8


The Zeroth Law of Quality

by Tony in QSM2

Many managers fail to recognize the relationship between their own actions and the results they’re getting. At best their actions are ineffective, but most of the time they are actually counterproductive.

They may know how to develop software but they don’t know the answer to the crucial question that all of us must ask ourselves: Why don’t we do what we know how to do?

One of the reasons we don’t do what we know how to do is that we are
confused by the multitude of problems. The first step out of this confusion is to realize that: Every software problem is a quality problem.

Think about it in terms of the Zeroth Law of Software: If the software doesn’t have to work you can always meet any other requirement.

In more general form, this becomes the Zeroth Law of Quality: If you don’t care about quality, you can meet any other requirement.

Quality, in fact, is producing things of value to some people: meeting their requirements. If you don’t have to meet their requirements, if quality doesn’t count, you can produce software with any number of features, at any price, as fast as you like. And your developers can think it’s great software. In short: If you don’t have to control quality, you can control anything else.

— Jerry Weinberg, Quality Software Management Vol 2, Chapter 7


The Rule of Three Interpretations

by Tony in QSM2

Whenever I’m aware that I’m making an interpretation, I have another choice: I can allow myself to know that more than one interpretation is possible. A good check on premature interpretation is the Rule of Three Interpretations:

If I can’t think of at least three different interpretations of what I received, I haven’t thought enough about what it might mean.

This rule slows down the Interpretation step and gives me, the receiver, a chance to engage my brain before using my mouth. Even after I have thought of three possible interpretations, however, I should always be aware of one more possibility: that my list still may not include your intending meaning.

— Jerry Weinberg, Quality Software Management Vol 2, Chapter 6


Comparing Promise and Delivery

by Tony in QSM2

Culture makes its presence known through patterns that persist over time. These patterns are not always consciously generated as patterns.

The same is true for software cultures. Their patterns can be seen in many ways. Before embarking on a program of detailed measurements, seek large-scale cultural measurements to guide your search. The conventional way of measuring an organization’s cultural pattern is by noting what they do. But we can also measure an organization’s culture pattern by comparing what they do with what they promise to do.

— Jerry Weinberg, Quality Software Management Vol 2, Chapter 5


Visualizing The Process

by Tony in QSM2

Steering (Pattern 3) cultures are distinguished by their ability to keep the product open to view. What distinguishes Anticipating (Pattern 4) organizations is the ability to keep the process open. In other words, Anticipating managers are not just steering the quality of each product, they are steering the quality of all products at the same time by steering the process.

Often, under pressure from customers or upper management, software engineering managers become desperate for anything visible to “prove” they have a stable process. In their desperation, they grasp at anything that’s easily measurable and has some apparent relationship with quality or productivity. That’s the reason for the almost universal enchantment of Routine (Pattern 2) managers with counting lines of code. Many of these managers do not even have a standard way to count these lines, not to mention a clear plan of action based on the count. Before working on clever ways of visualizing lines of code, we must be sure of exactly what we’re counting and what such counting will mean in the organization. If it proves meaningful, then by all means find a good way to make the meaning more readily perceived.

— Jerry Weinberg, Quality Software Management Vol 2, Chapter 4


Choosing Distortion or Redundancy

by Tony in QSM2

Project managers cannot afford the time to be entirely scientific when studying failure data. In order for them to control software processes, they must proportion their responses according to the significance of the data for the success of their projects.

— Jerry Weinberg, Quality Software Management Vol 2, Chapter 3


Measuring Precisely

by Tony in QSM2

Since Capers Jones got us started, we in the software industry have devoted significant effort to measurements of software quality and productivity. Much of this effort has been misspent in a search for illusory precision. It does no good to measure precisely if you don’t have a personal observation model that matches that level of precision.

Do you care if there are 3.7296 or 2.7297 rat hairs per sausage? Will it make any difference in your or my actions if I can measure the humor quotient, or even lines of code per programmer day, to four significant digits?

Measurement without models only allows extrapolation. If the previous five projects have produced 25, 26, 27, 28, and 29 function points per month of labor, then I can extrapolate that the next will produce 30. Such extrapolation is actually based on a model too – a model that says progress is linear. But this model is too crude and simplistic to reflect real software quality dynamics. Without a model, measuring with greater precision may enable us to make more precise extrapolations (more significant digits), but it doesn’t allow us to make more accurate ones (better correspondence with reality).

— Jerry Weinberg, Quality Software Management Vol 2, Chapter 2


First-Order Measurement

by Tony in QSM2

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.”

As John von Neumann said, “There’s no sense being precise about something when you don’t even know what you’re talking about.”

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.

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.

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.

— Jerry Weinberg, Quality Software Management Vol 2, Preface