Saturday, November 15, 2014

The Compulsion to Give Feedback

Continuing the the series of samples from various books, this week I'm posting a chapter from What Did You Say?: The Art of Giving and Receiving Feedback.
 The ebook version is posted on and other sites for only $9.99. It is also part of the Bargain Book Bundle, The Tester's Library, a collection of seven books for only $49.99:
Perfect Software and Other Illusions About Testing
Are Your Lights On: How to Know What the Problem Really Is
Handbook of Technical Reviews (4th edition)
General Systems Thinking: An Introduction
What Did You Say?: The Art of Giving and Receiving Feedback
More Secrets of Consulting: The Consultant's Tool Kit
Becoming a Technical Leader
The Aremac Project

The Compulsion to Give Feedback

The best way to convince a tenderfoot is to let him have his own way.

Even When Requested, Feedback Describes the Giver
Jerry was presenting a workshop in Lincoln, where he then lived. It was the first time he had offered this particular workshop, and he was quite anxious about how well it was going. At the end of the first day, Jerry gave Foster a ride home. While they rode, he asked Foster, "How did it go?"

Foster said, "Jerry, there's only one thing that I don't understand out of our discussion today."

"And what's that?" Jerry asked.

"If you're such a good consultant, why do you drive such an old car?"

Jerry may have thought he was asking for feedback about his workshop, or about himself. Instead, he got information about Foster. This suggests the first of The Giver's Fact:

Even when it's given at the receiver's request,
feedback describes the giver more than the receiver.

Why should this be so? The Satir's Interaction Model gives us some clues:

  1. The giver only perceives certain aspects of the receiver's behavior. Nobody can give feedback on behaviors that are outside of their perception.
  2. Second, givers then organize these perceptions in ways that are meaningful to them. Nobody will comment on things that they do not see as having meaning.
  3. The giver selects certain aspects out of thousands that might be commented upon, according to the emotional reaction triggered in them. That day, Foster happened to be interested in new cars.
  4. The giver's inner feelings and rules for commenting determine the style, choice of words, emotional tone, and non-verbal cues that comprise the entire feedback package.

All of this provides information on how the giver sees other people and behaves towards them. In fact, clever individuals often seek feedback solely to diagnose the giver, paying little or no attention to the content as it applies to them.

The Second Most Essential Human Need
The Giver's Fact says we reveal ourselves by giving feedback. Don't we respect our privacy enough to be unwilling to reveal so much about ourselves? So why don't we keep our feedback to ourselves?

The simple truth is that we cannot help ourselves. Giving feedback seems to be the second most essential ingredient of life itself–after air, and before water. Humans can live for about three minutes without air, three days without water, and three months without food. But according to our observations, most people cannot live more than three hours without offering someone else an observation about themselves–often in the form of advice.

Although we cannot hope to eliminate so fundamental a need, we might be able to help you tame your impulses. If we could stretch the three hours to four, or slow the reflex long enough for you to shape the feedback more appropriately, then we will have made an immense contribution to human welfare.

Perhaps the following facts about helping will help you not be so impatient to be helpful.

Nobility Isn't Good Enough
We often think since we're trying to help by giving feedback, it will be easy to succeed. As a result, we often become careless.

Fact: Wanting to help people may be a more noble motive than some, but that doesn't make feedback any easier.

Any time someone asks you for feedback–or even worse, pays you for feedback–you may think how smart and good you must be–so you grow careless. Giving or receiving feedback effectively always requires precise work. Careless feedback is a sure ticket to disaster.

They Have to Want It
If you're not absolutely sure they want your feedback, it's best to check it out. One way to check it out is by asking, which we seldom ever bother to do.

Fact: If people don't want your feedback, you'll never succeed in reaching them, no matter how smart or wonderful you may be.

We stress the importance of not giving uninvited feedback, not because it's morally wrong, but because it doesn't work. It's okay to do it if you don't care about your relationship with the other person. Or you don't mind wasting your own time. Indeed, that's a pretty good description of when you are likely to yield to the temptation to give unsolicited feedback:

We don't really care about the other person, and we don't have anything very useful to do with our time.

No Invitation is Forever
Even when you care about people who ask you for feedback, they may change their minds when they discover what your feedback will cost them. Once we start to give feedback, we often fail to recognize obvious clues that our feedback is no longer welcome.

What are such obvious clues? As the interaction advances, you may find yourself growing progressively more rude, impatient, and suspicious. If you feel that way toward someone you're trying to help, perhaps you're sensing that they don't want your help any longer.

Fact: Even when people agree that they want your help, that agreement is not usually a lifetime contract.

When you agree to provide feedback, you're not committed to continue giving it. You are committed to continue monitoring the situation to discover when the feedback is no longer wanted.
And then to stop.

Some Things Are Worse Than Failure
Just stopping seems hard to do, especially when "just one last word" will patch up the worsening situation. Whenever you find yourself thinking things couldn't get a lot worse, just remember that they can–a lot worse.

Fact: Even when you agree to give feedback to someone, that agreement need not be a lifetime contract. You're allowed to stop when you've had enough.

It's all right to admit you failed in your generosity, especially if it helps you stop before you make things a lot worse.

You Ain't No Saint
People who want to give feedback to other people generally expect to get something out of it for themselves–though they may not be aware of this expectation. Before you yield to the temptation to give feedback, become aware of your expectations.

Fact: There are very few living saints–at least, we've never had the pleasure of meeting any.

Most people agree that this moral applies to other people. Few people realize it applies to them. Certainly not any of your authors.

The Best Use of Giving Feedback
Giving feedback is often a way of exercising influence via the Trojan Horse. It looks as though it is for the benefit of the receiver but disguises the payoff to the sender. Regardless of the utility to the receiver, such feedback serves as a convenient vehicle for avoiding, displacing, attacking, gaining status, and justifying the status quo for the sender.

Fortunately for world peace, receivers can usually sense the existence of hidden motives in feedback. When they do, there's little chance of their accepting the ostensible message. If you're really interested in helping people, you'll do well to start your feedback by opening your own motives to inspection, perhaps by using the interaction model.

Of course, this seems a rather tedious way to start feedback, but most of the time, introspection and care with words will be far more efficient and effective than sending Trojan Horse Feedback. More often than not, however, we stop short of a full explanation of our motives. Instead, we settle for something quick, easy, comfortable, compatible, or self-limiting.

As a sender, your best use of feedback is to note your impulse to give, then reflect on what is going on inside you. There are unlimited opportunities of other things you might do to improve your relationships. What makes offering feedback your most appealing alternative? Have you become a feedback junkie? Have you forgotten there are other ways?


For the end of this year, I'm offering a list of bargain book bundles from Take a look at the books in each bundle by clicking one of these links:

Sunday, November 09, 2014

Measuring Requirements Ambiguity

Chapter 19 Ambiguity Metrics
Continuing the the series of samples from various books, this week I'm posting a chapter from Exploring Requirments Two, just posted to as a bargain bundle with Exploring Requirements One. - See more at:

Contrary to what some people think, requirements do have to be tested. At least, they must be tested if the project is to have a fighting chance of success. Part V of Exploring Requirements Two, develo specific ways in which requirements can be tested.
19.1 Measuring Ambiguity
The whole purpose of the requirements process is to reduce ambiguity in the development process, so the most basic test of any requirement is to measure its ambiguity. We've discussed requirements ambiguity, but the term "ambiguity" is itself ambiguous. There are many ways to reduce the ambiguity in "ambiguity," but the best would be to specify a precise way of measuring it. After all, there's little ambiguity in this requirement:
A. Draw a straight line on a blank sheet of 8.5" x 11" white paper, 13.150 ± .025 centimeters in length, .500 ± .025 centimeters in width, using a freshly sharpened Dixon Ticonderoga 1388 number 2 pencil. The line should be parallel to the top of the page, 2.000 ± .025 centimeters from the top, and touching the unbound edge.
On the other hand, we've already seen how much ambiguity there can be in a requirement that says:
B. Design a transportation device.
If "ambiguity" is a property of a requirement, then we'd like to be able to measure it in such a way that statement A has a small amount and statement B has a large amount.
19.1.1 Using the ambiguity poll
The ambiguity measure we will develop is based on something we already observed in the "Design a transportation device" example. We gave statement B to a thousand individuals, instructing them to work independently on a solution. As we saw, this problem statement lacks many essential ingredients, and we could have anticipated that each participant would resolve each one uniquely. Even if all solvers were trained to use the same design process, we'd be shocked to find that even two had produced exactly the same design.
Now suppose we gave statement A to a thousand individuals, working independently on a solution. The problem statement lacks a few essential ingredients, and since people are different, we would expect some individuals would create idiosyncratic solutions. Generally speaking, though, we'd expect there would be only a few variations, and most solutions would be indistinguishable.
This mental experiment suggests we can measure ambiguity as the diversity of interpretation. We have actually performed this experiment with large groups. For problem A, we measured the diversity by comparing the lines drawn. Everyone drew a single line, in pencil, and there were only minor variations in line length and placement on the page.
For the transportation problem (B), we gave each person one minute to develop a conceptual solution. At the end of that time, we asked each to give a single number as an estimate of the manufacturing cost of the proposed transportation device. Obviously, if they all had designed the same solution, their manufacturing costs would have varied somewhat, but not by much. In fact, for roughly a thousand people, the cost estimates varied from $10 to $1.5 billion. This ratio of 1,500,000,000/1 indicates an extreme difference of opinion regarding the meaning of the problem, but isn't that precisely what we mean by ambiguity?
Such a ratio of largest to smallest estimate in a poll of informed individuals can be used as an ambiguity metric, a measurable entity for which we can obtain a precise value. Of course, a precise metric may not be extremely accurate, but it's far better than no measure at all. Indeed, it's a rather practical measure, one we have often used in real design situations.
19.1.2 Applying the polling method
A manufacturer of precision electrical components was studying the feasibility of developing an automated system for handling catalog information requests. The company's president had cost estimates ranging from "moderately inexpensive" to "moderately expensive," and didn't know whether to authorize the project. We asked each of 14 qualified individuals to write an independent estimate of the project cost. The estimated amounts ranged from $15,000 to $3 million. When the company president saw this 200/1 ratio, he halted the feasibility study to wait for a less equivocal requirement.
19.1.3 Polling on different bases
"Manufacturing cost" is only one possible basis for an ambiguity poll. Others that come quickly to mind are
1. total design and development cost
2. worker-years required for design and development
3. number of unique parts in the solution
4. minimum calendar time required to deliver the first product
These measures would apply to any project, but others would be more specific. For instance, in the transportation device problem, we might ask for estimates of
5. efficiency: average energy consumption per hour of use
6. range: how far it could transport
7. capacity: maximum weight it could carry at one time
19.2 Using the Metric as a Test

One useful model of design says design is the process of removing ambiguity. In terms of this model, design proceeds through a series of steps: creating an approximate design, testing for ambiguity, removing the ambiguity found, and retesting the new approximation. Eventually, the tests say the latest approximation is close enough, and design stops.
(In the book, the text continues to explain in detail how to use the ambiguity metric as a test in several different ways.)


For the end of this year, I'm offering a list of bargain book bundles from Take a look at the books in each bundle by clicking one of these links:

(Get both Volume One and Volume Two in a single bargain bundle)

Sunday, November 02, 2014

Ambiguity in Stating Requirements

Continuing the the series of samples from various books, this week I'm posting a chapter from Exploring Requirments One, just posted to as a bargain bundle with Exploring Requirements Two.

Chapter 2 Ambiguity in Stating Requirements

Whenever your tools ignore the human aspect, you will describe requirements imperfectly and create ambiguities. Ambiguities, in turn, lead to diverse interpretations of the same requirement.
2.1 Examples of Ambiguity
For instance, Figures 2-1, 2-2, and 2-3 show three rather different structures built in response to the same ambiguous problem statement:

Create a means for protecting a small group of human beings from the hostile elements of their environment.

Figure 2-1. Igloo—an indigenous home constructed of local building materials.

Figure 2-2. Bavarian castle—a home constructed to impress the neighbors.

Figure 2-3. Space station—a mobile home with a view.
First of all, these three structures do represent effective solutions to the problem as stated, yet the solutions are strikingly different. Examining the differences among the solutions, we find clues to some of the ambiguity in the requirements.
Missing requirements
Sometimes requirements are missing. For instance, there is no requirement concerning properties of materials—properties such as local availability, durability, or cost. Thus, it's not surprising the three solutions differ widely in their use of materials.
The problem statement is equally ambiguous as to the structure, or how the building materials will be assembled. We don't know the desired size, shape, weight, or longevity of the structure.
Little is said or even implied about what functions will be performed inside these structures, leaving open the question of specific functional elements such as stoves, servants' quarters, beds, and ballrooms.
Nothing is said about the physical environment, either internal or external. The structure could reside on land, sea, or in the air, on an ice pack, or even in outer space. Then, too, we know nothing about the specific dangers from which we are to protect the inhabitants.
What about the social and cultural environment? Is this small group of human beings a family unit, and if so, just what constitutes a family unit in this particular culture? Perhaps it is a working group, such as hunters or petroleum engineers, or possibly a recreational group, such as poker players or square dancers.
Ambiguous words
Even when requirements are stated explicitly, they may employ ambiguous words. For instance, the word "small" does not adequately specify the size of the group. Beware of comparative words, like "small" or "inexpensive," in problem statements. A group of 25,000 would be "small" if we're talking about football fans at a University of Nebraska home game, where a new domed stadium seating 150,000 could fulfill the stated requirements.
Another dangerous word in the problem statement is "group," which implies the people will interact, somehow, but it's not clear how. A group of people performing The Marriage of Figaro don't interact in the same way as a group of people having coffee in the Figaro Cafe. Designing a structure for one group would be quite different from designing for the other.
Even the term "structure" carries a load of ambiguity. Some readers would infer "structure" means something hard, durable, solid, opaque, and possibly heavy. If we slip unconsciously into such an inference, we subliminally conclude the problem is to be solved with traditional building materials, thus limiting the range of possible effective designs.
Introduced elements
Of course, we can guard against ambiguous words by carefully exploring alternative meanings for each word in the problem statement, but that won't protect us from another problem. The term "structure" never actually appeared in the problem statement, but somehow slipped into our discussion without our noticing. The problem statement actually says "create a means," not "design a structure."
Some problem ambiguities are so obvious they would be resolved in casual designer-client conversations long before the actual design process began. More subtle ambiguities, however, may be resolved unconsciously in the designer's mind. In this case, an innovative, but nonstructural, "means" of protecting a small group might be overlooked. For instance, the designer might 
a. protect against rain by electrostatically charging the raindrops and repelling them with electrical fields.
b. protect against belligerent crowds by supplying aphorisms such as "Sticks and stones may break my bones, but names will never hurt me," or "I may have to respond to what other people do, but they don't define me."
c. protect against winter by moving toward the equator, and against summer by moving away from it.
2.2 Cost of Ambiguity
These few elementary examples of ambiguity in requirements can only suggest the enormous impact of the problem. Billions of dollars are squandered each year building products not meeting requirements, mostly because the requirements were never clearly understood.
For instance, Barry Boehm analyzed sixty-three software development projects in corporations such as IBM, GTE, and TRW. He determined the ranges in cost for errors created by false assumptions in the requirements phase but not detected until later phases. (See Table 2.1 and Figure 2-4.)

Table 2.1 Relative Cost to Fix a Requirements Error in Each Waterfall Phase
Although Table 2.1 vividly shows the importance of detecting ambiguities in requirements, the figures may actually be quite conservative. First of all, Boehm studied only completed projects, but some observers have estimated approximately one-third of large software projects are never completed. Much of the enormous loss from these aborted projects can be attributed to poor requirements definition.

Figure 2-4. Boehm's observations on project cost.
The situation looks even worse when we consider the catastrophes resulting from incorrect design decisions based on early false assumptions. For example, on the Ford Pinto manufactured in the 1970s, the position of the fuel tank mounting bolts was a perfectly fine design decision based on the assumption there will be no rear impact collisions. As this assumption proved to be false, the Ford Motor Company, by its own estimates, spent $100 million in litigation and recall services. And what value are we to place on the lost lives?
Or take another case. The decision by the Johns-Manville Corporation to develop, manufacture, and market asbestos building materials was based on an assumption: namely, asbestos in the form used in their products was environmentally safe to all exposed people. Many fine ideas found their way into Johns-Manville products based on what we now understand to be a false assumption. Epidemiology Resources, Inc. of Cambridge, Massachusetts estimated this high-level decision would eventually produce 52,000 lawsuits costing approximately $2 billion in liabilities. Indeed, the company's entire organization, culture, and capital investment was so dedicated to the production of asbestos materials that it went bankrupt and reorganized as the Manville Company.
2.3 Exploring to Remove Ambiguity
For the past three decades, we have both been working to help people avoid costly errors, failed projects, and catastrophes, many of which have arisen from ambiguous requirements. We have written this book to show you successful methods for exploring requirements in order to constrain ambiguity. These methods are general and can be applied to almost any kind of design project, whether it be a house in Peoria or a castle in Bavaria, an on-line information system or a manufacturing organization, an advertising campaign or a biking vacation in New Zealand.
2.3.1. A picture of requirements
Figure 2-5 is a picture illustrating what we mean by requirements. Many ancient peoples believed the universe emerged from a large egg, so we've used the "egg" to represent the universe of everything that's possible. We've drawn a line at the middle of the egg to divide what we want from what we don't want. If we could actually draw, or describe, such a line, we would have a perfect statement of requirements.

Figure 2-5. What we mean by requirements.
Figure 2-6 is a picture illustrating what we mean by exploring requirements. The first egg shows a rather wavy boundary representing the first approximation to the requirements line. This line might represent the first vague statement of the problem. The second egg shows the results of some early exploration techniques. The line is still wavy, indicating there are still some things described but we don't want, and some not described yet we do want. But at least some of the biggest potential mistakes (areas furthest from the requirements line) have been eliminated.

Figure 2-6. Exploring requirements: The black areas represent what we want but don't ask for, or what we ask for but we don't want. Through the repeated use of requirements tools, we reduce these areas and grow closer to what we want, and only what we want.
Each new egg, which represents the next stage in the requirements process, produces a better approximation to the true requirements line. Unfortunately, the line will never match the true requirements perfectly, because that's an almost impossible task in real life. Through explorations, though, developers try to make the line reasonably straight before paying too dearly for the wiggles.
2.3.2 A model of exploration
The process for straightening the wiggly line is an exploration, patterned after the great explorers like Marco Polo, Columbus, or Lewis and Clark. Roughly, here's what all explorers do:
1. Move in some direction.
2. Look at what they find there.
3. Record what they find.
4. Analyze their findings in terms of where they want to be.
5. Use their analysis and recordings of what they find to choose the next direction.
6. Go back to step 1 and continue exploring.

This is the same process used in exploring requirements, as we'll show in the rest of the book.


For the end of this year, I'm offering a list of bargain book bundles from Take a look at these bundles by clicking these links:

Tuesday, October 14, 2014

European Testing Excellence Award 2014

As some of you may know, I was honored last year with the 2013 EuroSTAR Testing Excellence Award. Well, it's that time of year again, and Eurostar 2014 has issued a call for nominations for the European Testing Excellence Award 2014.

The European Testing Excellence Award recognises leadership in and contribution to the field of software testing, and promotes the sharing and collaboration of best practices across the European Testing Community.

You have until November 14th, 2014 to send your completed nomination package (in strictest confidence) to

The 2014 winner will be announced at the EuroSTAR 2014 Gala Awards Dinner in Croke Park, Dublin, on Wednesday 26th November next.

Nomination must be received on or before November 14th, 2014!

Detailed nomination information is available here.

The Tester's Library

The Tester's Library consists of eight five-star books that every software tester should read and re-read. As bound books, this collection would cost over $200. Even as e-books, their price would exceed $80, but in this bundle, their cost is only $49.99. To learn why they should be in your library, go to

- Perfect Software
- Are Your Lights On?
- Handbook of Technical Reviews (4th ed.)
- An Introduction to General Systems Thinking
- What Did You Say? The Art of Giving and Receiving Feedback
- More Secrets of Consulting
- Becoming a Technical Leader

- The Aremac Project

Sunday, September 14, 2014


In keeping with my current efforts to lower costs for my readers/followers, I've created a number of discounted book bundles. The most recent of these bundles is the Quality Software BundleThis bundle is for managers, would-be managers, and any of us who find themselves being managed and confused.

This comprehensive bundle covers the entire span of software development approaches, from hacking through waterfall, cascade, prototyping, IterativeEnhancement, reusable code, to Agile teams.

The bundle explains all sorts of managers' behavior, from best to worst: how to achieve the best, how to improve the worst—or at least how to produce quality software in spite of it. Every truly professional software person will treasure this bundle as source of ideas for ever-increasing quality.

If purchased in bound volumes, these eleven books would cost more than $200. As ebooks, more than $100. But together, in this special bundle, the cost is only $49.99.

Bundle Contents:

How Software is Built

This volume tackles the first requirement for developing quality software: learning to think correctly about problems, solutions, and quality itself—setting guidelines to stimulate the kind of thinking needed.

Among the topics are quality, software cultures, patterns of quality, patterns of management, feedback effects, the size/complexity dynamic in software engineering, the role of customers, and how to diagram causes and effects.

Why Software Gets In Trouble
Why does software gets in trouble? Why not just say "people make mistakes"? Why not? Because there are reasons people make mistakes, make them repeatedly, and fail to discover and correct them. This book describes how companies and processes get into a state where errors are more likely to occur—increased pressure, high levels of stress, poor estimation, lack of control, and many more.

Why Software Gets In Trouble enumerates the ways errors occur and catalogs the effects of breakdowns caused those errors. Even more important, the book corrects many erroneous ways of thinking about those errors with principles such as, "Errors are not a moral issue" and "Quality is not the same thing as absence of errors."

How To Observe Software Systems
If they wish to produce high-quality software consistently in today's competitive marketplace, managers must have reliable information, obtained through careful observation and measurement. Here is a comprehensive guide to the basic measurement activities every organization must perform to manage the software development process.

Using a four-step model to break the complex observation process into a series of smaller, simpler, steps, First-Order Measurement teaches many ways to observe effectively. It defines the different levels of measurement, and describes the minimum set of activities in order to start an efficient measurement program.

Responding to Significant Software Events
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. It uses simple but effective models to explain human behavior, including 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.

Revieweres say it's enlightening, practical, humorous, and enormously inspiring, the book is brimming with simple techniques and examples of their application. It should be required reading for anyone who cares about project success—a must for all sentient software line and project managers.

Managing Yourself and Others
One of the main questions in software engineering (and perhaps in life) 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 a conflict or confrontation you behave congruently 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 vastly more effective in working with others. Many reviewers strongly recommend this book, and the rest of the Quality Software Series, to people who lead software projects.If you care about getting complex development projects completed on time, with high quality but without total team burn-out, read this book by Gerald Weinberg. Read it yourself, then give copies to your software team, starting with their managers. It's highly recommended."

Managing Teams Congruently
The former star programmer who now struggles with the challenges of management will find, in Weinberg, a mentor with decades of experience helping programmers, team leaders, and managers grow in the psychological and social dimensions of their professions. This book will probably make you think twice about some decisions you currently make by reflex. That alone makes it worth reading.

To be effective, team managers must act congruently. These managers must not only understand the concepts of good software engineering and effective teamwork, but also translate them into their own practices. Effective managers need to know what to do, say what they will do, and act accordingly. Their thoughts and feelings need to match their words and behaviors. As the book advises, "If you cannot manage yourself, you have no business trying to manage others." This book offers practical advice on how to act, and how to manage others congruently. Numerous examples, diagrams, models, practice suggestions, and tools fortify the author's recommendations.

Becoming a Change Artist
Very thought-provoking, with a lot of good concepts and models. If you wonder why you haven't been able to change your organization, Becoming a Change Artist is well worth reading. It illustrates how skilled people (Change Artists) work to create a supportive environment for software engineering —an environment in which your organization can realize long-lasting gains in quality and productivity by learning the artistry of managing change.

As the author argues, the history of software engineering is riddled with failed attempts to improve quality and productivity without first creating a supportive environment. Many managers spend their money on tools, methodologies, outsourcing, training, and application packages, but they rarely spend anything to improve or to remove the leaders who created those situations in the first place. From systems thinking to project management to technology transfer to the interaction of culture and process, this book analyzes models of how change really happens, and how change artistry creates the environment for all other changes.

CHANGE: Planned & Unplanned
This book is a must-read for anyone facilitating change in a software organization. It illustrates how to create a supportive environment for software engineering —an environment in which your organization can realize long-lasting gains in quality and productivity by learning how to manage change.

Major topics in the book include Meta-Planning: Information; Meta-Planning: Systems Thinking; Tactical Change Planning; Planning Like a Software Engineer; What Changes Have to Happen; Components of Stable Software Engineering; Process Principles; Culture and Process; Improving Process; Requirements Principles and Process; Changing the Requirements Process.

Change Done Well
Change Done Well is the ninth volume in the highly acclaimed Quality Software series. In it, award-winning author, Gerald M. Weinberg, illustrates how to create a supportive environment for improving software engineering —an environment in which your organization can realize long-lasting gains in quality and productivity by learning how to manage change.

The book addresses how to create an environment conducive to implementing the software engineering culture described in the first books of the series. What is fascinating about Weinberg's approach to software development management is how his perspective encompasses such diverse sources as family therapy theories, personality type studies, and experiences drawn from half a century of consulting for software development organizations.

Agile Impressions
Jerry Weinberg has been called "the grandfather of Agile Programming." Like all grandfathers, he watches his descendants with close interest and tries to help them succeed in life. In this book, Jerry offers us his grandfatherly observations and advice for those readers who want to grow up to be successful Agilists.

Inside, he describes some of the history leading up to Agile and looks at the strengths and weaknesses of the key Agile principles. He's looking foward to evolving his impressions by using the feedback from active Agile readers. If you're using Agile, or thinking about using Agile in the future, Agile Impressions will give you much of the background you need to be successful.

Freshman Murders
Freshman Murders is the opening story in the Residue Class Mysteries. It's added to the Quality Software Bundle to illustrate many of its principles in action. The series is dedicated to the proposition that, when solving mysteries, as with developing quality software, there's no substitute for brains backed by courage. The detectives who solve these crimes are nerds–brilliant individuals whose social skills may not equal their skills in mathematics, computers, and science.

On the terrified campus of Hurlesburg U., Mathematics Professor and former NSA problem-solver Josh Rosemont, finds a young woman’s body in the woods. He is paralyzed by her resemblance to his murdered daughter. As the murders continue, he is enraged into action by an obstructive Dean. Teaming with his cop-turned-anthropologist wife, Carmela, and his four genius grad students, he sets out to prevent another murder.

Blending every skill and trick of their professions, Rosy's team hounds a twisted trail of false clues to uncloak the Dean’s sex scandal, decipher incriminating evidence in a billion-dollar swindle, and thwart the serial killer–a deranged student who believes raping and killing a potential suicide is not really murder.But did they catch the real killer?

Order now for instant delivery: Quality Software Bundle

More Bundles

I would appreciate if you would tweet this link to your interested friends.


Thursday, July 31, 2014

The Tester's Library

This week, I'm trying something different—The Tester's Library.

I've written many books, which is good, but sometimes the sheer number creates a financial problem for my fans. To make collecting the books easier on fans' wallets, I've begun to put together bargain-priced bundles of books to form beginning libraries for different audiences. At the moment, I'm planning a Tester's Library, a Developer Library, a Consultant's Library, and a Manager's Library. Perhaps more will come later.

The first one, The Tester's Library, can be found at

I won't release them all at once, leaving a bit of breathing room between one library and the next. This week, I've started with the Tester's Library, which consists of eight five-star books that every software tester should read and re-read. As bound books, this collection would cost over $200. Even as e-books, their price would exceed $80, but in this bundle, their cost is only $49.99. Here are the books, and why they should be in your library:

  • Perfect Software and Other Illusions About Testing
James Bach says, "Read this book and get your head straight about testing. I consider Jerry (Weinberg) to be the greatest living tester."
Perfect Software sets the stage for the bundle by answering the questions that puzzle the most people, but whose answers must be on the lips of every professional software tester:
• Why do we have to bother testing?
• Why not just test everything?
• What is it that makes testing so hard?
• Why does testing take so long?
• Is perfect software even possible?
• Why can't we just accept a few bugs?

  • Are Your Lights On: How to Know What the Problem Really Is
The tester's fundamental job is to identify problems in systems. Whether you are a novice or a veteran, this powerful little book will make you more effective at precisely identifying and describing problems. Any tester involved in product and systems development will appreciate this practical illustrated guide, which was first published in 1982 and has since become a cult classic. Are Your Lights On provides an entertaining look at ways to improve one's thinking power and the power to communicate effectively about problems discovered in testing:
  • First how to identify the problem.
  • Second how to determine the problem's owner.
  • Third who to discover where the problem came from.
  • Fourth how to decide whether or not to solve it.
Delightfully illustrated with 55 line drawings by artist Sally Cox, the book has changed the way thousands of testers think about the job of producing quality software.

  • Handbook of Technical Reviews (4th edition)
Experienced testers know that technical reviews are probably the most powerful testing tool. Every tester should participate in reviews, and this book explains how to do it.
One reviewer said, "For me there are many, many valuable lessons in this book. Not only does it provide a step-by-step explanation of how to run software reviews and how to get them accepted in the organization, what is even more important is that everywhere the "why" behind choices is explained. That allows me to transfer sound principles to a wide variety of settings. In every company reviews "work" slightly differently, and this book has helped me figure out how to match the implementation to the specific setting."
"Quite apart from the great content, I found the writing style a delight: witty, chock full of wisdom, and a breeze to get through. At over 400 pages it "looks" like a tome, but I went through it like a breeze. And I keep returning to it, which says a lot about the depth of coverage."

  • General Systems Thinking: An Introduction
For many years, An Introduction to General Systems Thinking has been hailed as an innovative introduction to systems theory, with applications in software development and testing, medicine, engineering, social sciences, architecture, and beyond. Used in university courses and professional seminars all over the world, the text has proven its ability to open minds and sharpen thinking.
A reviewer wrote: "In computing, a timeless classic is anything that is worth reading for any reason other than to obtain a historical context after five years. If that still holds true after twenty five years, then it is truly an extraordinary piece of work. That label applies to this book. It is not about computing per se, but about how humans think about things and how 'facts' are relative to time, our personal experience and environmental context."
"This is a book that is a true classic, not only in computing but in the broad area of scholarship. It is partly about the philosophy and mechanisms of science; partly about designing things so they work but mostly it is about how humans view the world and create things that match that view. This book will still be worth reading for a long time to come and it is on my list of top ten computing books.

  • What Did You Say?: The Art of Giving and Receiving Feedback
Perhaps the most important—and most difficult—of the tester's jobs is giving information to developers about problems in the software they produced. This brief and engaging book can be of use to anyone who has to interact with other people. You'll enjoy the "read" so much that you may not realize how much you have gained - all in words of one syllable! 
• How to offer feedback when asked (or hired) to do so.
  • Why feedback tells more about the giver than the receiver.
  • How feedback is distorted or resisted by the receiver's point of view and defense mechanisms. 
  • How humans have struggled to understand each others' responses.
One reviewer wrote: "If I had the power to transport one book back in time and send it to myself, this would be the one. This is the book I needed when I became a people manager. It's also the book I needed when I began to raise my kids. In fact, I can't think of a time in my life when I did not wish I had more of the skills this book teaches. A simple but very deep book that causes a new level of understanding about how to talk to people with each reading."

  • More Secrets of Consulting: The Consultant's Tool Kit
Ultimately, a tester's job is like a consultant to developers, advising them on how to improve their products. Like all consultants, testers need tools to help them have their advice used productively.
Here's how a reviewer described the book: The "Consultant's Tool Kit" of the subtitle is actually a complex metaphor. Each component of the toolkit is a metaphor for a certain aspect of your personality and personal capabilities. For example, the wishing wand is a metaphor for understanding, and being able to ask for, what you want from a professional relationship. The chapter around this metaphor first explores why most people either don't know what they want or are unable to express it, and suggests ways to make your wishes clearer. It places this in a professional context, contract negotiation, and emphasizes how the personal ability to express and value your wishes will help you negotiate more successfully. 
In a similar way other chapters focus on developing wisdom and new knowledge, managing time and information, being courageous with your decisions, learning how to say yes and no, understanding why you and others are in the current situation, and keeping yourself in balance, avoiding burnout and other self-destructive conditions. 
These are all important not only to consultants, but to anyone trying to establish a more satisfying professional or personal life by managing problems, by self-improvement and by better handling their relationships to other people.

  • Becoming a Technical Leader
Ultimately, the best testers are leaders, guiding their organizations to better quality software products. Becoming a Technical Leader is a personalized guide to developing the qualities that make a successful technical leader. We all possess the ingredients for leadership, some better developed than others.
The book focuses on the problem-solving style–a unique blend of skills in 3 main areas: innovation, motivation, and organization. Ways to analyze your own leadership skills, with practical steps for developing those skills.
From one tester's review: "It is most difficult for a technical expert to transition from a individual contributor to a leader. This book tells you exactly how to do that !!! Brilliant, witty and extremely enjoyable. One of raw all-time classica on leadership. If you have only one book to read on leadership then this is it."

  • The Aremac Project

  • This is an intriguing fictional story, based on true events, showing how software testing, done well or done poorly, makes all the difference in the outcomes.

    Thank you for reading. If you'd like, please use the green button below to share this news with your Tester Friends.