Monday, December 08, 2014

Free Books for Gift Giving


At this point in my professional life, at my advanced age, most of what I do professionally is teach workshops and write—mostly write. I don't write for money. All my writing income is given to charity: animal rescue, research on animal health, and civil liberty education (over $500,000, so far).

I write to pass along what I've learned, just as others have passed along their learnings to me. My goal is to reach as many readers as possible. Consequently, I'm always trying to think of ways to reach new readersm, and for this holiday season, I've thought of a way you can help me reach that goal.

Here's the deal. When you buy one of my ebooks, you can easily copy that book and give it to your friends and colleagues. If my primary interest was the money, I wouldn't be happy to know you're copying the ebook. But, although I do want money to go to my charities, I'm pleased that that a free copy has gone to someone who might otherwise not even know it exists.

So, this year, when you buy one of my books, I encourage you to copy it and give it to someone who might otherwise not know it, or could not afford it.

Yes, I know you could do this without my encouragement, but I also know that some readers don't feel right about taking something for free. And, generally, that's not entirely honest, so I'm not encouraging you to do this for other authors without their permission. But for my books, you have my permission, so go ahead and copy with a clear conscience.

(If you want to "pay" me, drop me a little email note saying how many free copies you distributed. That will satisfy my curiosity, and might encourage me to make this offer every year.)


BARGAIN BUNDLES

To make this offer even more attractive, remember that I'm offering a list of bargain book bundles from Leanpub.com. Take a look at the books in each bundle by clicking one of these links:
Experiential Learning (3 volumes @$45)


Fable Bundle (2 volumes @$7.99)


Residue Class Mystery Series (3 volumes@$11.99)


Quantum Stringer Series (3 volumes@$14,99)


The Testers Library (8 volumes@$49.99)


Secrets of Consulting  (2 volumes@$14.99 )


Quality Software  (11 volumes@$49.99)


General Systems Thinker Bundle (5 volumes@$29.99 or less)


Requirements  (2 volumes@$14.99)


Using these bundles with the copying offer, you'll be able to fulfill an enormous gift list with minimal expense.

Thursday, December 04, 2014

Gifts for Any Time, but Especially Now


Now that we're finished with that Black Friday and CyberMonday hysteria, it's time for my annual Christmas poem:

Twas the week before Christmas,
And all through the house,
Every creature was fretting
And starting to grouse.

Then from UPS
Came a gift flowerpot
From a friendly old colleague
Whose gift I'd forgot.  

But then I remembered:
Don't feel like a schnook
In just a few minutes
I can send a great book

No wrapping, no breakage,
No address to scrawl,
No trade-ins, no trouble,
'Cause one size fits all.

So boot up your browser,
And don't be a schnook.
In a fistful of keystrokes
You can send a fine book.

Naturally, I recommend one of my novels for a fun read and fitting gift—perfect for smart adults and bright teenagers.

For just $6.99 each (or less when buying more than one), you can go to http://www.thewomenofpower.org to read about each story and what reviewers said. Then you can send your friends engaging, exciting stories, each one that also carries one or more science/technology themes. 

These novels are my attempts to put the science back in science fiction and the techno back in techno-thrillers.

The Residue Class Mysteries Themes
The Freshman Murders: Computers, Culture, Genealogy
Where There's a Will There's a Murder: Mathematics, Anthropology
The Death Lottery: Randomness, Programming, Espionage

The Quantum Stringers Series Themes
Quantum String Quartet: Physics, Social Psychology
Quantum String Sextet:: Team Building, Communication
Quantum String Band:: Space Travel, Psychology

The Women of Power Series Themes
Mistress of Molecules: Chemistry, Politics
The Hands of God: Parallel Computing, Neurophysiology, Prosthetics
Earth’s Endless Effort: Unconventional Computers, Alien Contact

The Aremac Project Series Themes
The Aremac: Software Development, Testing, Security
Aremac Power: Risks and Rewards of Invention

And, of course, Computers in every story!

And if you've already gifted everyone on your list, I invite you to try one of my novels for yourself. As always, if it doesn't fit for you, I’ll gladly return your money.

Have a wonderful Holiday every day,
Jerry

p.s. You can also gift your techie friends with some of my non-fiction ebooks: See Leanpub.com

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 Leanpub.com 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?
_______________________

BARGAIN BUNDLES

For the end of this year, I'm offering a list of bargain book bundles from Leanpub.com. 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 Leanpub.com as a bargain bundle with Exploring Requirements One. - See more at: http://secretsofconsulting.blogspot.com/#sthash.lSTCEoew.dpuf

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

BARGAIN BUNDLES

For the end of this year, I'm offering a list of bargain book bundles from Leanpub.com. 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 Leanpub.com 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.

BARGAIN BUNDLES

For the end of this year, I'm offering a list of bargain book bundles from Leanpub.com. 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 Lorraine@eurostarconferences.com

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 https://leanpub.com/b/thetesterslibrary/

- 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

QUALITY SOFTWARE BUNDLE

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.

http://secretsofconsulting.blogspot.com

Thanks.