The Anti-Esteem Tool Kit

The self-esteem tool kit consists of tools you can use to build your self-esteem. For instance, the wishing stick (or wand) reminds you that it's okay to think about what you want, instead of always deferring to the desires of others. Or, the thinking cap reminds you that it's okay to come to your own conclusions about what's going on in the world.

These tools all help you to raise your self-esteem, but there's another tool kit, one that helps you remember to put aside certain tactics that simply help you to maintain low self-esteem. Here's some examples:

The Bully Club: Low self-esteem people often think they can feel better if they hurt other people. Sometimes they think the Courage Stick is a form of bully club, but that's a mistake.

The Blame Pointer: Low-self esteem people are often found pointing the finger of blame at others.

The Blindfold: This tool enables a person to go through life not seeing anything they don't want to see.

The Earplugs: By plugging their ears, people are able to avoid hearing anything that might make them uncomfortable. Some Earplugs replace all sound with distracting music. Some just totally deafen to all sounds. Both the Blindfold and the Earplugs counteract the positive effects of the Golden Key, a tool that allows you to open any inquiry you're puzzled about.

The Nose Clamp: This double-duty tool keeps their wearer from remembering to breathe with their Oxygen Mask. It also prevents the wearer from smelling the stink that everyone else is aware of in a situation.

The Stupid Pill: A single one of these pills drugs one's mind to counteract the effects of wearing a Thinking Cap which would otherwise have you thinking as clearly as possible.

The Last Aid Kit: - Use this to bandage your wounds after agreeing to requests you can’t fulfil because you did not use your Yes/No medallion.

Do any of these tools remind you of any politicians you know?

So, what other anti-esteem tools do you have in your tool kit?

For more on the Self-Esteem Tool Kit, get yourself a copy of More Secrets of Consulting: The Consultant's Tool Kit.

https://leanpub.com/moresecrets

The Most Important Aspect of Software Testing

On a public forum, the question was, "What are the most important aspects of software testing?"

A number of good answers were given, but all tended to emphasize finding errors. To me, that's a limited view of testing. I would say, instead, that the most important aspect of software testing is to provide information about the state of a software product. That is, not just errors, but what's good and bad about the product. And, by the way, what's just mediocre.

For instance, the speed of the product might not be in error, but could be good, bad, medicre, or perhaps acceptable to some or all possible users. It's the tester's job to document that.

Or, there may be a feature that works okay, but is not so easy to use. Is that an error? Who knows, but in any case, it's a fact that the sponsor of the project will usually want to know about, and providing that information is the tester's job.

One more example: if a tester merely finds and reports errors, small wonder that developers feel that testers are nattering nabobs of negativity. Test reports should describe what's good—what's wonderful—about a product, and testers must never forget that part of their job.

You can read more about important aspects of testing in my book, Perfect Software And Other Illusions About Testing.

Challenge 9: Organizing The Grand Tour

When you stop learning, stop listening, stop looking and asking questions, always new questions, then it's time to die... - Lillian Smith

One of the most important sources of ideas for change is ideas that have already worked in a similar organization. Moreover, one of the most supportive acts you can perform is to ask someone to teach someone else what they do well. When people teach other people about what they are doing, it forces them to become aware of their own processes.

The Challenge
Your challenge is to organize a tour of your work place for other change artists. Have the people in your workplace teach the change artists "what we do well that others might want to imitate."

Experiences
1. I thought this was a silly assignment—until it paid off with a savings of about $40,000 a year in our printing operation. One of the programmers on the tour had never seen an actual high-volume printer in operation. Once she understood the way things worked, she easily changed one of our major applications so that weekly printing was significantly faster.

2. We found that their performance analyzer did things that we never imagined. We felt a bit foolish using the crude tool we had concocted, but I was proud that we didn't defend it in the face of an obviously superior product (change artist training helped with that). With more than a little help from their team, we switched tools—and, as a side benefit, no longer had to maintain our homemade kludge.

3. The effect on my group was fantastic, and that really surprised me. First they grumbled about all the trouble it would be to prepare for the tour, but then they started cleaning house. It was like when my mother comes to visit—I clean the toilets and put away things that have been laying out for months. The group did the same thing with their code and their supporting documentation. I don't know if the visitors got anything out of their visit, but they sure saw a clean operation. And—this is the best thing—it stayed clean. Actually, I do think they got something out of it, because we've been asked to give four more tours to groups where someone wants to clean house.

4. Well, we didn't learn much, and they didn't learn much, except that we do things pretty much the same way. I guess that's confirming. And I learned that they're nice people. Perhaps in the future we'll be able to help each other, and that feels good even if we don't have any specific current benefits to show.

Reference

This post is part of the series, adapted from the book, Becoming a Change Artist.

The Myth of Writers Block (and what to do when you're blocked)

Writing is one of the most important activities for successful consultants. Writing helps you capture and clarify your ideas. Writing helps you polish your presentations to clients. And published writing is probably the second most effective marketing tools in your kit. (First, of course, is recommendations from satisfied clients.)

Yet most consultants never publish an article. Of those who do publish an article, most write only one. Many consultants never publish a report. Of those who do publish a report, most write only one. And certainly, most consultants never publish a book. Of those who do publish a book, most publish only one. If you ask them why they don't write more, they will commonly say they are stuck, or "blocked." But these words are merely labels. They explain nothing. Most often consultants stop writing because they do not understand the essential randomness involved in the creative process.

The Structure of Creation versus the Structure of Presentation

Please don't get the impression that I read in the random way I write (my "Fieldstone Method." Reading, by its nature, is more or less linear, like a string of beads, and I tend to read most works through from beginning to end. But written works can be created by superimposing any of a variety of organizations on that linear string of words. For instance, novels, being stories, are more or less linear; but novelists may use flashbacks, stories-within-stories, or parallel stories to break the linearity.

Dictionaries, encyclopedias, and reference manuals—though consisting of a bound sequence of pages—are generally organized for a random access by the addition of tables of contents and indices. Internets and intranets allow us to hyperlink written works in much more complex structures, though in order to use them, we frequently need aids such as index pages and search engines.

But none of these reading organizations have much of anything to do with the organization of the creative process by which the works came into existence. These reading structures are presentation methods, not creation methods. Creation doesn't work in any such regular way. It's more accurately modeled by the Fieldstone Method. Every day is different; every idea is different; every mood is different; so why should every project be the same?

Writer's Block and the Goldilocks Questions

"Of course every day is different," you may say. "Some days I'm entirely paralyzed by writer's block, and I don't accomplish anything at all."

If this is your problem, I can help, as I've helped many other consultants and professional and amateur writers. I didn't always understand how I was helping, until one student wrote the following:

As evidenced in some conversations with other students of yours and in my own writings, I think there are number of intangibles that you do offer—in much the same way that a coach or therapist does. These include motivation, raising self-esteem, building confidence in writing, considering self-other-context, discipline, thinking more clearly, or awareness, to name only a few.

Writer's block is not a disorder of you, the person attempting to write. It's a deficiency of your writing methods—the mythology you've swallowed about how works get written—what my sometime co-author, Tom Gilb, calls your "mythodology." Fieldstone writers, freed of this mythodology, simply do not experience "writer's block." Have you ever heard anyone speak of “mason's block”? (But, yes, I have heard people talking about "consultant's block"—and what I'm saying here actually applies to much of the work consultants do, or try to do when they get "stuck.")

Many writing methods and books assume that writer's block results from a shortage of ideas. Others assume the opposite—that writers become blocked when they have a surplus of ideas and can't figure out what to do with all of them. But it's not the number of ideas that blocks you, it's your reaction to the number of ideas.

Here's how it goes. You have the wrong number of ideas, and that bothers you, causes you discomfort, or even pain. To lessen the pain, you turn to some other activity—coffee, beer, sex, movies, books, sleep, or name your poison. This diversion relieves the pain in the short run, but eventually your mind turns back to that unfinished piece of writing (or other work). Now you feel worse because you've avoided the task. You might try writing again, but your mind keeps returning to what a bad, blocked writer you are. So, eventually, you turn to your relief—coffee, beer, sex, or whatever.

Do you recognize the addiction cycle? (This dynamic is described more fully in my soon-to-be released Volume 5, Managing Yourself and Others, of my e-Series, Quality Software.) The Fieldstone method allows you to break this cycle in exactly the same way you break any addiction, by using your intelligence and creativity. I sometimes begin to feel "blocked," but when I do, I simply ask myself what I call the Goldilocks Questions:

"What state am I in now? Do I have too many ideas? Do I have too few? Or, like Baby Bear's porridge, is it just right?"

If I have too many ideas, I begin some organizing activities, like sorting ideas into different piles. If I have too few ideas, I concentrate on gathering more. Usually, the first place I look is in my own mind, staying in the flow of the moment, one idea building on the next.

For instance, when I’m writing dialogue, I don’t stop to search externally for just the right conversational “stone.” That approach leads to overly clever dialogue, rather than the more natural-sounding stones that just pop out of my head from millions of past conversations I’ve heard or overheard. Only if my natural mental flow fails me do I start searching for an external "fieldstone" to trigger a new flow.

Then, when the number of ideas is "just right," I organize them, trimming and polishing a bit in the process, until I have a finished product—or until I have to ask the Goldilocks Questions again. Sure, I may be stuck for a few moments, but I'm never "blocked."

In my book, Weinberg on Writing, I sketch all three parts of the Fieldstone Method—first the gathering of ideas (stones), then the organizing, then the trimming and polishing. The book describes them in that order, not because I perform them in that order, but because it's a book, and books are linear organizations of ideas.

Unlike what your schools taught you about writing, the Fieldstone Method is not dependent on any particular order of doing things. Instead, Fieldstoning is about always doing something that's advancing your projects. As a Fieldstone writer, you will have a variety of keep-moving activities, a handy list of tasks of all sizes, plus the knowledge to match each task to your mood, your start/stop time, your resources, and your total available time. As a Fieldstone consultant, you will have a second handy list of keep-moving activities—a list with your writing list as one of its sublists.

Each Fieldstone writer also has to find her own “magic” tasks, not all of which may seem “logical” to other writers. Meditation works for me, but others find it disturbing. Aikido boosts me, but it tires others. Some writers say you have to have a cat, a cigarette, and a cup of coffee laced with brandy.
The cigarette and brandied coffee would kill me, which would be merciful because then I wouldn’t have to watch the Lovey and Caro tear apart the cat.

Observing Your Activities

In order to be a non-blockable writer (or consultant), you need to do a bit of observation of yourself. Here's what I suggest you try:

1. Choose a day or several hours that you plan to devote to writing.

2. In your journal (all professional consultants keep a journal) record the start-stop time of different activities.

3. Record your feelings at the beginning and end of each activity. Don't interrupt your flow, but just capture a word or two.

4. At the end of the day, look at what you wrote in your journal. Do you see an addiction cycle?

5. How did you respond any time you were temporarily stuck?

6. What other activities could you have done that would have served you better?

7. How will you remind yourself of those activities when you repeat this observation exercise in a month or so?

(This article is adapted from Weinberg on Writing: The Fieldstone Method )

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Find my eBooks sampled free, and offered for sale at these stores

• My Barnes and Noble page

• My Amazon Page

• Apple Store

• My Smashwords Page
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Parable of the Ones

This little essay on the consequences of choosing the wrong measurements is taken from my book, How to Observe Software Systems

One way to avoid missing important observations is to observe everything. This strategy is neither humanly possible nor economically feasible. Resources devoted to observing one thing detract from the resources available to observe other things. Perhaps that's why some Routine managers are so fond of huge "metrics" programs—as a distraction from the things they really should be observing, but don't know how to observe without being overwhelmed.

Consider the Parable of the Ones:

Merlin the Manager was tired of being chastised by his boss, Wanda, for low programmer productivity. "How can I show you that the programmers are doing something," he asked her, "when all they're ultimately producing is ones and zeros."

"I'm not interested in zeros," Wanda complained. "Zeros are nothing. How many ones are they producing?"

"Um, I don't know," Merlin stammered.

"Well, you're their manager," Wanda accused. "You should know."

"Of course," Merlin apologized, backing out of Wanda's office. "I'll institute a metrics program."

Merlin then hired some measurement consultants who showed him how to count the ones automatically in every object program, plotting them by project and programmer. The initial report showed an overall productivity of 43.78% ones, and Merlin called a meeting of all the programmers to chastise them about their low productivity.

"Look at this figure," he accused. "This means that 56.22% of all bits on memory are essentially unused—filled with zeros. Why, when I was a programmer, I could generate programs at random that were 50% ones. If this keeps up, there won't be any performance awards this year, I can assure you."

Two months later, just before the performance awards were decided, Merlin looked at his metric report and was delighted to discover that the overall productivity figure was 53.04% ones. He showed this report to Wanda, who gave him a big bonus. "Well," he thought, "that certainly shows the value of a measurement program. Now, as soon as I fire those two programmers with less than 45% ones, productivity will show another boost."

Merlin, of course, was merely illustrating DeMarco's principle. If he rewards programmers for ones, he'll get ones. Even without explicit rewards and punishments, the mere fact of observing something implicitly reinforces it. Workers always notice what their managers notice—and what they fail to notice.

As often happens, Merlin's "measurement" system has produced a backwards effect from what the organization really wants (see diagram of effects on left). If he interprets the production of zeros as wasted effort, he encourages programmers to put effort into producing ones, which really is wasted effort. Much of the effort that might have gone into correct, well-performing software has gone instead into beating the measurement system.

Testing Without Testing

The job of software testing, we know, is to provide information about the quality of a product. Many people, however, believe that the only way to get such information is to execute the software on computers, or at least review code. But such a belief is extremely limiting. Why? Because there's always lots of other information about product quality just lying around for the taking - if it were only recognized as relevant information.



Because of their psychological distance from the problems, external consultants are often able to see information that escapes the eyes and ears of their clients. Dani (Jerry's wife) tells this story about one of her consulting triumphs in the dog world:



======================================================



A woman with a Sheltie puppy was at her wits' end because "he always poops on the living room rug." She loved the little guy, so before giving up and taking him to the Humane Society, she came to Dani for a consultation. Dani listened to the woman describe the problem, then asked, "Are there any other behavior problems you've noticed?"



The woman thought about that for a while, then said, "Well, yes, there is one. He has this annoying habit of scratching on the front door and whining."



======================================================



It's easy to laugh at this woman's inability to see the connection between the two "problems," but that sort of blindness is typical of people who are too close, too emotionally involved, with a situation. Learning to recognize such free information is one of the secrets of successful testing. Using it, you can learn quickly about the quality of an organization's products or the quality of their information obtained from machine testing.

Here are some "Sheltie stories" from our consulting practices. Test yourself by seeing what information you can derive from them about the quality of a product or the quality of the information that's been obtained about the product through testing:



======================================================



1. Jerry is asked to help an organization assess its development processes, including testing. Jerry asks the test manager, "Do you use specs to test against?"



Test manager replies, "Yes, we certainly do."



Jerry: "May I see them?"



Test manager: "Sure, but we don’t know where they are."



======================================================



2. Jerry is called in to help a product development organization's testing group. He learns that they are testing a product that has about 40,000 lines of code.



"The problem," says the test manager, "is with our bug database."



"What's wrong with it," Jerry asks. "Is it buggy?"



"No, it's very reliable, but once it holds more than about 14,000 bug reports, its performance starts to degrade very rapidly. We need you to show us how to improve the performance so we can handle more bug reports."



======================================================



3. Bunny is asked to help improve the testing of a large product that has 22 components. The client identifies "the worst three components" by the high number of bugs found per line of code. Bunny asks which are the best components and is given the very low bugs per line of code figures for each.



She then examines the configuration management logs and discovers that for each of these three "best" components, more than 70 per cent of their code has not yet successfully been checked in for a build.



======================================================



4. Trudy is invited to help a development manager evaluate his testing department's work. She starts by looking at the reports he receives on the number and severity of bugs found each week. The reports are signed by the test manager, but Trudy notices that the severity counts have been whited out and written over.

"Those are corrections by the product development manager," the development manager explains. "Sometimes the testers don't assign the proper severity, so the development manager corrects them."



Using her fingernail, Trudy scratches off the whiteout. Under each highest severity count is a higher printed number. Under each lowest severity count is a lower printed number.



======================================================



5. Jerry is watching a tester running tests on one component of a software product. As the tester is navigating to the target component, Jerry notices an error in one of the menus. The tester curses and navigates around the error by using a direct branch.



Jerry compliments the tester on his ingenuity and resourcefulness, then asks how the error will be documented. "Oh, I don't have to document it," the tester says. "It's not in my component."



======================================================


6. Fanny watched one tester spend the better part of several hours testing the scroll bars on a web-based enterprise system. The scroll bars were, of course, part of web browser, not the system being tested.



======================================================



7. Jerry asked a development manager if the developers on her project unit tested their code.

"Absolutely," she said. "We unit test almost all the code."



"Almost?" Jerry asked. "Which code don't you unit test?"



"Oh, some of the code is late, so of course we don't have time to unit test that or we'd have to delay the start of systems test."



======================================================



8. One of Christine's clients conducted an all-day Saturday BugFest, where developers were rewarded with cash for finding bugs in their latest release candidate. They found 282 bugs, which convinced them they were “close to shipping.”



They were so happy with the result that they did it again. This time, they found 343 new bugs - which convinced them they were “on the verge” of shipping.



======================================================



9. A general manager was on the carpet because a recently shipped product was proving terribly buggy in the hands of customers. Jerry asked him why he allowed the product to ship, and he said, "Because our tests proved that it was correct."



======================================================



10. Another manager claimed to Noreen that he knew that their product was ready to ship because "we've run 600,000 test cases and nothing crashed the system."



======================================================



11. When Jerry asked about performance testing, one of his clients said, "We've already done that."



"Really?" said Jerry. "What exactly have you done?"



"We ran the system with one user, and the response time was about ten milliseconds. Then we ran it with two users and the response time was twenty milliseconds. With three users, it was thirty milliseconds."



"Interesting, Jerry responded. "But the system is supposed to support at least a hundred simultaneous users. So what response time did you get when it was fully loaded?"



"Oh, that test would have been too hard to set up, and anyway, it's not necessary. Obviously, the response time would be one second - ten milliseconds per user times one-hundred users."



======================================================



12. Jerry's client calls an emergency meeting to find out "why testing is holding up our product shipment." In the meeting, the testers present 15 failed tests that show that the product did not even build correctly, so it couldn't be tested. They discuss each of the 15 problems with the developers, after which the development lead writes and email summary of the meeting reporting that there are only two "significant" problems.



The email goes to the development manager, the marketing manager, and all the developers who attended the meeting. None of the testers present are included in the cc-list, so none of them even know that the email was sent.



======================================================



13. Johnson watches a tester uncover five bugs in a component, but instead of logging the bugs in the bug database, the tester goes directly to the developer of the component and reports them orally. Johnson asks why the tester didn't record the bugs, and he replies, "If I do that, she (the developer) screams at me because it makes her look bad."



======================================================



14. Tim reviews a client's test plan and notices that there is no plan to test one of the components. When he asks the test manager (who is new to the company) why it's missing, he's told, "We don't need to worry about that. The development manager assures me that this developer is very careful and conscientious."



======================================================



So, were you able to extract meta-information from these ten examples? What did each of them tell you (or hint to you) about the quality of the information from testing - the accuracy, relevance, clarity, and comprehensiveness?

Remember, though, that these are merely hints. Perhaps the Sheltie pooped on the rug because he had some medical problem that would need a veterinarian's help.

Perhaps there's a non-obvious explanation behind each of these Sheltie Situations, too, so you always have to follow-up on the hints they provide to validate your intuition or find another interpretation. And, even if your intuition is right on target, you probably won't have an easy time convincing others that you're correct, so you will have to gather other evidence, or other allies, to influence the people who can influence the situation.



When Dani asked the Sheltie's owner why she thought the pup was whining at the front door, the woman said, "I think I've spoiled him. He just wants to go out and play all the time, but I have too much housework to do - especially since I spend so much time cleaning up the mess on the rug."



When a problem persists in spite of how obvious the solution is to you, you aren't going to be able to convince others to solve the problem until you find out how they are rationalizing away the evidence that's so apparent to you. So we need to know how people immunize themselves against information, and what we can do about it.

(Adapted from Perfect Software: and Other Illusions about Testing)
http://www.smashwords.com/books/view/25400

First Stringers: A free version

Book View Café offers you a chance to buy this exciting science fiction novel from Jerry Weinberg, absolutely free.

Amplify’d from www.bookviewcafe.com

Gerald M. Weinberg

First Stringers

In the near future, a group of handicapped twenty-one-year-olds with the ability to control the string structure of the universe, find each other and form an alliance against the people and organizations who would hunt them down and use their powers to conquer the world. As they discover one another they must strive to master their abilities, overcome their conflicts, face their personal fears and discover their deepest values in order to become more fully human.

First StrFirst Stringers

Book View Cafe is pleased to present First Stringers in free serial form.

First Stringers is also available in trade paperback and as an ebook. Read more at www.bookviewcafe.com

 

See this Amp at http://amplify.com/u/8w09

Attendance Too Regular? Try This!

Inspired by Ajay Balamurugadas's blog at

http://enjoytesting.blogspot.com/2010/08/aware-of-other-side-of-your-application.html

The title was Enjoy Testing

which starts with:

"For the past few months, I left office at sharp 6 p.m. I felt I should not invest more hours just because someone's estimate was wrong. So, I always took the 6 p.m. cab to home instead of the 8 p.m. or 10 p.m. cab."

And Michael Bolton commented:

"...I perceive that resolution to the trickiest part of the problem starts with recognizing people."

Michael is right. It starts with people. And guess who is the first person to recognize?

Yourself, of course.

The very first thing that struck me about the (quite fine) post was the regularity with which you come and go to work. Ordinarily, such regularity is a highly valued trait. For example, people can count on knowing when you'll be there and when you won't. Very good contribution to communication--and thus very high on every tester's list.

However, as an experienced tester, you already know that too regular, too predictable, behavior is a way to miss a great many bugs--and that's true of the regularity in attendance, too.

I would suggest you come in a couple of hours early on some random day next month, and (on a different day, probably) leave quite late. And, if you have people who work night shifts, arrange to be around for one or two of those.

I probably didn't have to explain why, but some of Ajay's readers may be less experienced than others. Experienced testers can probably all tell stories of when they came in early or left late (or were somewhere they weren't usually expected to be, or even prohibited to be) and because of that noticed something that led to a bug they never would have seen otherwise. (Perhaps something they were totally unaware of.)

I myself can tell many such stories, including one that may well have saved astronauts' lives, so I regularly practice being somewhat irregular in my behavior as a consultant (yes, I know that's a paradox).