Gerald Weinberg's Secrets of Writing and Consulting

A Christmas Present for My Readers: A Free Story

2012-01-23T15:18:00.000-08:00

This year I created a Christmas present for all my faithful readers. It's about one of the characters in my series of novels, The Stringers–Ember, a blind girl with extraordinary powers. The story is titled "The Blind Warrior," and it's free.

I wanted to put the story free on Amazon.com, but Amazon took a long time to make it a free story. They finally did, but now it's too late for Christmas, so I'm doing it anyway. To obtain your copy of The Blind Warrior, go to smashwords.com. You will find the story at this address:

http://www.smashwords.com/books/view/106977?ref=JerryWeinberg

Or, on Kindle, it's at

http://www.amazon.com/dp/B006CDQEYK

And it's even on Barnes and Noble, for you Nooknicks:

http://www.barnesandnoble.com/w/the-blind-warrior-gerald-m-weinberg/1107956526?ean=2940032888451

It's free of all charges, and you can download the story in any format you need (Smashwords has 'em all, or in more than one format). You can read the story on your computer, or you can transfer it to any other device.

Of course I have an ulterior motive. I hope you will like the story so much that you will want to read more about Ember and her Stringer friends. Or maybe you'll write a one-or-two sentence review.

Find all my books through http://www.geraldmweinberg.com, including the Stringer Series, so far.

Problem Solving Leadership Workshop (Revisited)

2012-01-17T10:00:00.000-08:00

Today, I'm revisiting a post I put here almost exactly three years ago. At that time, I was announcing the resumption of PSL (Problem Solving Leadership Workshops). Today, I'm announcing the continuation of what has become a treasured tradition.

We're giving the next offering of the famous Problem Solving Leadership (PSL) on May 19-25, 2012, in Albuquerque, NM led by me, Esther Derby, and Johanna Rothman

The workshop's purpose is to learn and practice a consultant's most valuable asset: the ability to think and act creatively. We have designed this workshop to be practical and applicable to the modern workplace. Your problems and concerns provide a frame of reference for all
the workshop activities.

What you will learn
. to be a leader while being a member of a team
. to focus your thinking while in chaos
. to make change a productive, creative event
. to build truly effective teams
. to design projects people really want to work on
. to observe exactly what is happening
. to use tools of effective communication
. to handle conflict in problem solving groups

The workshop provides five and a half days of intensive focus on developing your unique consulting style and abilities.

Graduates Answer: "What Did You Learn in PSL?"

Janet:

My PSL course made me realize that observation alone is not enough. Sometimes you need to get in and ask questions and listen to really know what's going on.

Amy:

It's interesting to reflect on this fourteen years after the fact (Sept. 1997) of what was a profound experience. My biggest observation was my tendency to pick problems that are too big to be solved—or at least solved all at once or on the term initially envisioned. And my lesson was that I could turn to others and ask for help parsing the problem into resolvable packets. I'm still using that one every day. . . when I remember to step back and observe the observer observing.

Jim (who sent me the panda picture):

I took PSL in 1983 (Jacksonville, Fl.). At the time I learned a valuable lesson about myself. I have a tendency to cling to an obsolete and inappropriate technology long after it is no longer effective. Years later, taking training facilitated by amateurs (managers saving money on their training budget) I learned how important it is to have qualified trainers and good exercises.

Marjie:

I learned so many ways to help my teams back home become self - sufficient problem solvers by teaching. I became far more self-aware of my own behavior which was to just solve the problem and try to make life easier for everyone else when in fact, it was much more relaxing to give people the skills to solve their own problems (at least the tricks I learned at PSL) and to watch them do great things.

I learned that Jerry's expression, "expect brilliance"—became the motto of my management style.

Sharon:

Big lessons, life-changing, agreed. The immediate lesson was: respond. That is, I found that sometimes, in the heat of the moment, I would listen, hear, see, take in and wait, processing the inputs. That was good. But most important was once I did that, I should give feedback, respond, react. Even if other people are responding, get into the mix and say what needs to be said.

The long-term lesson was that there is a fabulous community around us all. Jerry and others became part of an extended community that has vastly changed what work I do, how I do it, and to whom I reach for support.

Becky:

Sharon, I like your point about community! I've connected with delightful, smart and engaging people who shared a similar path through JerryWorld. Not to mention the wizards who helped lead us down the path—all of those who encouraged us to be our own wizards. Gee - I hadn't thought of that.

PSL - the gift that keeps on giving.

David:

I started learning to listen to myself, instead of asking others for validation before believing myself. Something that has served me well since then, and that I'm still learning to do better."

Rachel:

I think I'm still unpacking lessons from PSL :)

I signed up for PSL because I was uncomfortable with taking on leadership roles. I feel happier about taking the lead nowadays. For me the key is sharing passion and vision for what's possible and make it easy for people to contribute in their own way. It's important to step back and let others shape things whilst caring how things are done and being there as support when people get stuck.

I'd love to do PSL over again and also connect up with people I met there.

Jason:

I seem to have 'aha' moments often since PSL in May 2011. A couple things stand out for me. One, how Jerry talked about having fun and learning at work. So simple, yet something I live by. If I'm not having fun or learning, I move on.

Second was observing the difference in outcomes between a controlling culture and cultivation culture. I'm also amazed at in a short period of time how many people I became very close to. It was a fantastic experience.

Zeger:

Hi all, I took PSL in May last year, and what has stuck with me, well... that's still evolving. I was an observer during the VerseWorks exercise and it struck me how much you can see and learn about what is going on in teams if you just take a step back and observe. When you're too involved, you become blind for things that are apparent to outsiders. Noticing all that going on and refraining from commenting or pointing out was quite hard. That was quite a epiphany for me.

I also became aware of the power of silence. Doing or saying nothing can also be an act of problem-solving leadership, helping the team forward. Sometimes, less is truly more. That was a pretty sobering insight too.

Jerry:

I've "taken" PSL many, many times, and I'm still learning lessons with every workshop. Mostly, I keep learning how many wonderfully creative people are out there, always ready to take one more step toward their full potential.

If you would like more information about in this unique workshop experience, email to
jr@jrothman.com and/or take a look at http://www.estherderby.com/workshops/ProblemSolvingLeadership.htm

Change Artist Challenge #12 Developing Yourself

2012-01-15T11:10:00.000-08:00

A book (or a blog) can give you only what the author has to tell. But the learning that comes through self-knowledge has no limit. To learn through your own self-knowledge is to know how to listen, how to observe, and therefore you learn from everything: from music, from what people say and the way they say it, from anger, greed, ambition. - Jiddu Krishnamurti

The biggest benefit from change artistry comes when you start teaching other people to be change artists.

The Challenge
Your challenge is to make up a change artistry challenge of your own, one that will give you practice in an area you need most. Accept your own challenge and offer it to others.

Source

This is the last of the dozen challenges from Becoming a Change Artist. Additional exercises in the book may help you, but from now on, your job is to practice, practice, practice.

Change Artist Challenge #11: Putting Theory Into Practice

2012-01-05T12:14:00.000-08:00

There's nothing more practical than a good theory. - Kenneth Boulding

Reading a book is one thing. Applying what you learn is quite another. If you don't apply it soon, it simply fades away. The same is true of any educational experience. If you come back from a class and don't start using some of the material, you may as well not have gone in the first place.

The Challenge
Your challenge is to review the chapters in any of the four Quality Software Management volumes concerning specifics of the Anticipating organization and consider each idea in terms of the artistry that you can use to introduce it to your organization. Try to create at least one specific action item that will advance the transformation to that way of doing things.

Experiences
1. I started a brown bag special-interest group on our new CASE tool as a place for people who were using it to share learnings, and as a low-risk place for those who weren't using it to find out about it. The hardest part for me—and the real challenge—was to be the first speaker. I haven't been a person who enjoys speaking in front of groups, but I got some support and made myself do it. The group now runs on its own—with little nudges from me once in a while—and there's no trouble getting speakers. It has tripled in size as our use of the tool has grown, and people think that without the group the tool would have died in the original group, or at least not spread.

2. I set out to measure something that would be useful to upper management and to the people whose work was being measured. After a few false starts, I hit upon measuring resolution time for failures found in test. I set up a system to capture this data from our bug database and to plot it automatically week by week. One of the surprising things it showed was the way the new configuration management system actually slowed down resolution time. Since I was advocating the new system, I was rather disappointed, but I resisted the temptation to fudge the figures. Management wanted to throw the system out, but I invoked the Satir Change Model to get a few weeks grace period. With the help of some investigation into the causes of Chaos, the graph improved. In about three weeks, the resolution time was back to what it was before the tool, and after six weeks, the time was cut by 32%. This was the first time anyone had ever demonstrated the value of a new tool in our organization.

3. My challenge to myself was to open up information in my organization. To do this, I decided to be the model by using Public Project Progress Posters for the three projects I'm managing. I was surprised by the emotional reactions—mine and others'. I was apprehensive and defensive, yet proud of my courage. One of the other managers came into my office, shut the door, and started screaming obscenities at me for embarrassing him (because he wasn't going to post his progress). The people in the projects were generally accepting, though I spent a lot of time in the next two weeks explaining how to read the posters, what certain slippages meant, and what I was going to do about them. It was a lot more trouble than I anticipated, but now that things have settled down, it seems to be worth it.

Reference

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

Change Artist Challenge #10: Learning from History

2011-12-14T22:54:00.000-08:00

The liberation of a tree is not the freedom from its roots.- Rabindranath Tagore
The Grand Tour shows you what's going on now, but perhaps more interesting to a change artist is how things got the way they are.

The Challenge
Your challenge is to discover the history of some practice that you consider non-productive.

Experience#1
1. Darn you! This assignment almost got me fired. I started questioning why we chose our LAN software and then it came out that my boss was the one who made the study that led to the decision. We got into a BIG argument over what I considered a dumb choice that was really hurting communication around here. He gave me a copy of his original study (actually, he practically shoved it down my throat) and I grudgingly read it. I was halfway into it when I realized that they really had chosen the best that was available at that time. The system I was favoring didn't even exist then. I don't think the company that makes it even existed then. I didn't know that; I didn't even think of that. Well, I learned a couple of things:

• Don't argue with the boss until you have all your facts straight. (I suppose I knew this, but needed reinforcing.)

• Everybody really is doing the best they can, with what they have, at the time they do it.

• I'm likely to make the same mistake (if it really is a mistake) of not seeing far enough into the future.

• An apology actually works with my boss, and doesn't kill me (though it embarrasses me).

Experience#2
While studying how we used consultants in the past, I learned that we have a pattern of paying them a lot, putting in a lot of work with them, and then putting their reports on the shelf. I don't know what I'm going to do about this, but obviously something has to change. Perhaps we won't hire consultants any more, or we'll hire different ones, or we'll work with them differently. Maybe we're expecting too much from a report.

Experience#3
I found out why we put quarters in the bowl at meetings when somebody interrupts someone else. That started before I came to this group. Now we give that money to charity, but originally it was used for beer after the meeting. I've re-instituted the beer-sharing—we really needed some kind of team-building, or team-repairing like that. Don't worry, though. We still give the quarters to charity, and just take turns buying the beer.

Experience#4
I wanted to find out what really happened to the previous two process groups. I did. I'm going to make a few changes, right away.

Experience#5
Well, I couldn't do this assignment. I wanted to study the history of our weekly status meetings, but I couldn't find anyone who remembered how they got started. I couldn't find anyone who remembered why they got started. I couldn't even find anybody who knew why we were still doing them. So we're not doing them any more. But I didn't do the assignment.

Reference

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

Disposable Programs (Part 2)

2011-12-06T08:45:00.000-08:00

There are many reasons why a program brought out of hibernation could incur costs:

1. The hardware environment has changed.

2. The system software environment has changed.

3. The size or format of the data has changed.

4. The human environment has changed.

5. Some part of the program or its supporting material has been lost or damaged.

So it does cost to rerun an "unchanged" program, and the longer the period of hibernation, the greater the cost. But you already knew this—we all know this. Then why, oh why, do we keep tumbling into the same trap?

Part 2
I believe the answer lies in our unwillingness or inability to feed-back the true costs of programming and program maintenance to our users. Among our service bureau clients, the problem seems to have been brought to manageable proportions by the following steps:

1. When a program is commissioned, the lifespan and the number of executions must be specified.

2. If there is uncertainty about either of these ﬁgures, contingent prices are given, reﬂecting the differing costs.

3. The contract is written stating that the program will be destroyed after a certain time and/or number of runs, whichever comes ﬁrst.

4. The program remains the property of the service bureau, unless the customer takes ownership—in which case a much higher cost is placed on the job, in order to pay for preparing the program to be taken over by other than the original programmers.

5. The customer is notified when the program is about to be destroyed, and is given the option (at a substantial and realistic price) of having the program rebuilt for further use.

6. If the program is a "one-time" program, no notification is given, but the program is destroyed—literally—as soon as the customer agrees to accept the results.

When working with inexperienced users, it is not difficult to get these terms accepted. Neither is it difficult with very experienced users, who know quite well the realities of "one-time" programs that turn out to be "N-time" programs. Only the in between users have difficulty accepting these conditions, for they believe they understand about programming, but actually have no solid basis for understanding.

After a few costly lessons, they are more than willing to sit down in advance and decide whether they want to invest in an N-time program or merely in a disposable program that will actually be disposed of.

In internal data processing situations, especially where there is no true chargeback for programming or program maintenance, these lessons are difficult to teach. There is no cost to the users of specifying a one-time program and then asking that it be run N times. Without cost, there is no motivation to learn.

Where there is chargeback, it is possible to do what good, professional service bureaus do. Without chargeback, you can sometimes achieve some relief by manipulating the one parameter you have available—time. You request the user to specify a one-time or N-time program and then give different time estimates for each. The one-time estimate is shorter, but carefully spells out the procedure that will be followed in destroying the program after its ﬁrst use.

At ﬁrst, users will not believe this procedure will be enforced. After a few lessons, they will begin to understand and devote some energy to the decision. Of course, some users will simply attack the computing center manager, or the programmer, with an axe, literal or ﬁgurative. Such are the perils of our profession. Besides, even an axe in the forehead is better than the pain in some lower anatomy caused by an immortal one-time program.

Disposable Programs

2011-11-30T14:42:00.000-08:00

In many IT installations today, the number one problem is program maintenance.
Although the total problem is far from simple, there are a number of relatively simple ideas that can be applied immediately to furnish "prompt relief." One such idea is the disposable program.

The idea of disposable programs is not new. Every programmer has written code that was to be used once and then thrown away—codes such as:

1. First-cut subroutines, as for simple, quick formatting of output.

2. One-time reports.

3. Test drivers.

4. Research programs to probe some peculiar feature of the programming language, operating system, database, or other "black box."

5. Engineering assist programs, to help diagnose a particular hardware malfunction.

If you consider these ﬁve examples relative to your own experience, you will notice two categories:

KEPT: ﬁrst-cut routines, and one-time reports, and

DISPOSED: test drivers, research programs, and hardware testers. That is, though all are thought of as single use programs, the KEPT routines tend to be held, somewhere, "just in case." Only the DISPOSED programs are actually discarded, whether they should be or not.

Can you recall an instance when you wished you had actually retained a discarded program?

And can you recall cases of KEPT programs you devoutly wish you had destroyed when you had the chance? These are the programs you see and curse almost every day, as their user phones, pleading for "just one little change."

Perhaps we would immediately begin improving the maintenance situation by applying two simple rules about "one- time" programs:

1. If you are about to throw it away, keep it.

2. If you are about to keep it, throw it away.

Unfortunately, applying these two rules together creates an inﬁnite recursion. All programmers would be instantly paralyzed. There must be a better way. (Or do you believe that instant paralysis of all programmers would be of great benefit to the human species?)

Consider the examples once again; you'll notice that the underlying principle seems to be:

If the programmer is responsible for the decision, the program is discarded; but if the user is responsible the program is kept.

But why not just keep all programs, for all time? There are many reasons why a program brought out of hibernation could incur costs:

1. The hardware environment has changed.

2. The system software environment has changed.

3. The size or format of the data has changed.

4. The human environment has changed.

5. Some part of the program or its supporting material has been lost or damaged.

So it does cost to rerun an "unchanged" program, and the longer the period of hibernation, the greater the cost. But you already knew this—we all know this. Then why, oh why, do we keep tumbling into the same trap? And how do we get out, or stay out, of the trap.

Well, we'll watch for readers' ideas on these questions, and next blog entry, I'll give a few ideas of my own.

Who is Right, and What is to Be Done About It? (2)

2011-11-24T16:35:00.000-08:00

Today, I give the rest of the story as it actually happened, then consider some of the astute comments given already.

What the Consultant Did
The consultant was astonished by the programmer's response: "That's not an error. Actually, the formula was in error, so I corrected it. The formula I programmed is correct, whereas the original formula was simply wrong."

The consultant understood, which the programmer did not, that a program error occurs when the program does not do what the customer wanted, not what the programmer thinks the customer should have wanted. That was the programmer's first mistake.

The programmer's second mistake was not understanding who his customer was. He seemed to think that the French were the customer, but the actual customer was the consultant.

(NOTE: If the actual customer had been the French, the programmer's action was still wrong, because of his first mistake. If a programmer thinks his customer has asked for the wrong thing, he could, politely, bring this thought to the customer's attention. So, if the French had been the customer, the programmer's third mistake was not bringing his thought to them. And even if the customer had been correctly identified, the programmer's fourth mistake was being rude and arrogant. That's simply not the way to get your point across, especially if your point is that your customer has been wrong.)

What the Consultant Said
"You didn't understand your assignment," the consultant said. "We're trying to simulate the precise formula used in France so we can compare it to the formula used in other countries. It's not a question of right or wrong, but merely of matching the existing French formula."

"Well," the programmer replied, "anyone with half a brain and a smattering of knowledge of inventory theory can see immediately that the French formula cannot possibly be correct, so what's the sense of programming it? Tell them to use my formula, if they want to improve their inventory management."

The management consultant decided to try another approach with the recalcitrant programmer. "That's a good idea. If you're right, I'm sure they'll really appreciate getting a better formula. In the meantime, it will help them to accept the new formula if they can see how it compares with their original one on this data, so I'd appreciate having their formula programmed as soon as you can manage."

"You don't seem to understand," the programmer insisted, "Why should I waste my valuable time on a formula I know is wrong? Just show them my formula and they'll understand."

At this point, the management consultant gave up on the programmer and got himself another one. The French formula was programmed and found to give the claimed results which were, in fact, superior in many circumstances to the approaches used in other countries. It turns out that the programmer's fifth mistake was overestimating the "correctness" of "inventory theory."

Readers' Comments
A number of readers correctly (I believe) said they would try talking with the programmer. In the actual case, the consultant tried this, but learned that the programmer was not going to listen. Perhaps this was the consultant's fault in the way he tried to talk to the programmer, but in any case, if your employee (and the programmer was, of course, working for the consultant) won't talk with you about a situation, then you have to get rid of that employee. So, attempting to talk is a good approach, in that it gives you essential information even if the programmer refuses to talk.

Other readers warned the consultant to consider his own role carefully, and to consider myriad possible interpretations of what's going on. This is always good advice for a consultant.

Several readers correctly identified one or more of the programmer's mistakes (above). Clearly, someone needs to educate the programmer about what his job is, and how to do it, but evidently the consultant lacked the skill to accomplish that. So, again, the consultant needs to consider his own role, at least for the future. In a similar situation, for example, he might take more care in choosing the programmer and/or making the programmer's task much clearer from the outset.

Those who advised the consultant to get "on the ground" with the inventory application were also on a productive track. In this case, the consultant was in the USA, and meekly accepted the refusal to pay him to travel to France and study the French approach first hand. If the consultant knew what he needed but didn't insist on having it, he made a major consulting mistake. If you insist, but your client won't supply it (time, or access, or money, or whatever), then the consultant should simply resign from that assignment.

Using specific examples rather than simply theory—what a good idea. Both the consultant and the programmer were probably "intuitives" in the MBTI sense, so they kept the discussion on the level of theory, which often misses some crucial data. In this case, if the French formula actually worked in practice, that would have thrown an entirely different light on the discussion.

Next Steps
All in all, the case example seems to have done its job—namely, stimulating an outpouring of darn good advice about consulting and programming.

Now that you have the "whole story," what further observations would you like to make as comments?

Who is Right, and What is to Be Done About It?

2011-11-22T23:00:00.000-08:00

A management consultant, whose client was an international manufacturer, was asked to evaluate an inventory management procedure that the client had used with stunning success in their French operations. As part of his study, he wanted to compare the performance of the French procedure with procedures used in other locations, using historical data from several countries. A programmer with a strong management science background was given the job of programming the simulation of the French procedure.

When the consultant received the results he could not reconcile them with the ﬁgures supplied by the French company. After extensive checking he initiated a series of long telephone calls to France, suggesting that perhaps the procedure had not actually performed as well as they had claimed. The French management took offense at the implication of incompetence.

The French manager complained to the manager who had hired the consultant. Tempers mounted and international relations were strained to the breaking point.

By sheer chance, someone examined the programmer's simulation program and noticed that one term was missing and a second term was negative rather than positive. These findings led to a full technical review of the formula as translated. The review showed that the programmer's formula did not match the formula supplied by the French.

The consultant, much relieved, took the program back to the programmer and showed him the error. "That's not an error," the programmer protested. "Actually, the formula was in error, so I corrected it. The formula I programmed is correct, whereas the original formula was simply wrong."

That's the end of Part 1.

Note to Readers
Now, for you readers, the question is this:

"If you were the consultant, how would you handle this situation going forward?"

If I receive a few comments, I'll publish the rest of the story—what actually happened.

And please note: I don't accept anonymous comments. They're automatically rejected. By all means, use a pseudonym, but don't waste your effort trying to post anonymous comments.

Iterative Development: Some History

2011-11-10T21:21:00.000-08:00

As an old guy who's been around computing since 1950, I'm often asked about early history of computing. I appreciate efforts to capture some of our history, and try to contribute when my agin memory doesn't play tricks on me.

Back in 2003, Craig Larman and Victor R. Basili compiled an interesting article, Iterative and Incremental Development: A Brief History. I made several contributions to their history, but they did much, much more. Here's a small sample of what I told them:

We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBM's Service Bureau Corporation]. He was a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural. I do remember Herb Jacobs (primarily, though we all participated) developing a large simulation for Motorola, where the technique used was, as far as I can tell, indistinguishable from XP.

When much of the same team was reassembled in Washington, DC in 1958 to develop Project Mercury, we had our own machine and the new Share Operating System, whose symbolic modification and assembly allowed us to build the system incrementally, which we did, with great success. Project Mercury was the seed bed out of which grew the IBM Federal Systems Division. Thus, that division started with a history and tradition of incremental development.

All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities… I think what the waterfall description did for us was make us realize that we were doing something else, something unnamed except for "software development."

Larman and Basili's article has a whole lot more to say, and as far as I know, is an accurate history. I strongly recommend that all in our profession give it a good read. We should all know these things about ourselves.

Challenge 9: Organizing The Grand Tour

2011-10-24T11:33:00.000-07:00

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.

Review: September issue of Tea-Time for Testers

2011-10-20T09:15:00.000-07:00

I've just finished reading September issue of Tea-Time for Testers, a free and useful e-magazine for the testers of the world. Here's a few comments I have to offer the magazine and its readers and potential readers.

- Selena Delesie's article is a gem. I wish all testers would copy the article and use it to lay out a learning plan for themselves. She leaves us no excuses of the sort "I don't have time for learning" or "there's simply no learning opportunities where I work." On flaw: she writes, "See my website for some books, websites and blogs I recommend." I tried the link, but couldn't find the list she mentions. I wish the link went directly to the list of recommendations that's hidden somewhere in her site.

- Anurag Khode's article on testing network connection speed is on a topic that interests me. It's highly specific and useful for that reason. Conversely, for a tester without these specific problems, probably nothing is lost by skipping the article. I wish Anurag had given a few general conclusions that might help testers in other situations. As it stands, the article itself is one model of setting up tests, but I suspect few testers will take advantage of that feature unless it's specifically pointed out.

- On the other hand, I look forward to Joel Montvelisky's articles precisely because they address the issue of applying intelligence. In this article, he tackles the application of intelligence in an area that many testers think doesn't require thinking at all: automated testing. He deserves a medal for courage, because I fear that some advocates of automated testing will lambast him for suggesting that you need to think once you've automated some tests.

Anyway, those are a sampling of the articles I enjoyed in the September issue. As usual, I read TTWT from cover to cover (even though it has no covers). As for the issue as a whole, I always love the colorful illustrations throughout the issues.

You can find the latest issue at http://www.teatimewithtesters.com/

Trying to Change a Dysfunctional Organization

2011-10-18T08:10:00.000-07:00

Today, I'm continuing my problem-solving series with a letter from Rory, asking how to change his organization. Rory's situation should be familiar to anyone who has been literally thrown into "testing" in a dysfunctional organization.

Rory
Your books have already helped me and are continuing to help me, but I have a specific scenario at work right now and I have what I think is a good solution, but I'd really appreciate your take on the matter.

I seem to be very unhappy in Variable or Routine organizations, and I really want to work in a Steering organization, but as I've learned from you they are few and far between.

Jerry
By Variable, Routine, and Steering, Rory is referring to the cultures described in my Quality Software series.

Rory
Therefore, I want to try my hand at changing the organization I work in because a) I'll be happier (I think) and b) I think the company will be better off as well. However, after re- reading Chapter 12 of "Becoming a Technical Leader" I'm very mindful of not inflicting help. I went through an exercise where I documented the situation objectively, and then observed my feelings about it. I will include what I documented below my signature. I wanted to share it with you because I thought you might find it interesting, but I'm also interested in any help you could offer on the matter.

Rory's Exercise
The situation:
- Product Manager mentioned a new scenario to me one day before the product was supposed to be released to production.

Jerry
Strike one. Strike two. And Strike three. Out already.

Rory
- The application is currently in the staging environment where testing is supposed to center around verifying the configuration is correct.

Jerry
Huh?

Rory
- The new scenario revealed a bug.

Jerry
Was anyone surprised by this?

Rory
- The developer in charge of the part that was broken updated the stored procedures to account for this.
- After testing it again there were new errors and the feature did not work at all.

Jerry
Was anyone surprised by this?

Rory
>- After an additional change the new scenario is still not working
>correctly and an old scenario is no longer working correctly.

Jerry
Was anyone surprised by this?

Rory
More context:
- The work for this feature was handed down by a manager. Each programmer was assigned a certain area of the application to code.

Jerry
Meaning the manager had already done design work?

Rory
- I started testing this on my fifth day at the company after the design reviews were completed and I report to a different manager than the programmers.
- The product manager reports to a different manager as well.
- We have never held a retrospective on the feature.
- The feature design is not documented.

Jerry
Was anyone surprised by this?

Rory
How I feel right now:
frustrated, sad, stressed, unhelpful, confused, detached from team, hopeless

How I feel about the feelings:
- I feel a little silly for letting something that is not life or death frustrate me or make me sad.
- I feel weak for not knowing how to change the situation or myself so that I don't feel these things.

Jerry
Don't try to get rid of the feelings. Instead, learn how to use them productively. If after all this, you weren't feeling frustrated, sad, stressed, unhelpful, confused, detached from team, then there would be something wrong with you.

As for hopeless, well, there isn't much hope there. There's an enormous amount to do to change an organization that acts like you've described, and you can't do it alone. So, the first step for you is to quietly see if you can recruit a few allies. If you can't, then you should leave and find a better organization.

Rory
- I feel afraid that I may lower my professional integrity in order to increase my happiness which in the long run may make me less happy.
- I feel incompetent for feeling confused.

Jerry
No, in fact, only an incompetent person would fail to feel confused in such a situation.

And just how do you mean, "lower my professional integrity" in order to increase your happiness? In my experience, people who lower their professional integrity soon become terribly unhappy that they did it. So don't!

Rory
A brief summary of what I think bothers me the most:
We aren't working together as a team on this issue, and I feel unrelated to the problem and to the other people working on it.. I believe we're working in an inefficient way which doesn't fulfill my need to become more competent at delivering quality software. My autonomy is compromised, because I feel like the developers are using me to re-test something just to check that the code fix they made worked instead of checking it themselves before taking my time. (I feel guilty for feeling that way.)

Jerry
If it's true, then there's no reason to feel guilty.

You need to be talking with people about your feelings. That's the way to find allies--or to find out there are none to be had.

Rory
I also want to sincerely help the company deliver a great product and spend as little time and money as possible to do it, and I don't see us finding ways to improve.

Jerry
You have to find others who see things that way.

Rory
What I would like to do:
If I were an outside consultant (and I was asked to help) then I would probably schedule a meeting with the actual people involved and hold a retrospective. Then I would go from there.

Jerry
That's too big a chunk from where you are. You need to recruit support, one person at a time. If you're seen to be doing this, and then you're labeled as "subversive" and/or "not a team player," then the place is hopeless.

Rory
However, I was involved in this, and I think that some people would be offended that I'm asking them to come to another meeting.

Jerry
Again, don't try to get everybody. Change happens one person at a time.

Rory
Based on this I think my best option right now is to ask someone who was not involved in the feature and who seems to have a lot of respect and admiration to schedule and facilitate a retrospective for us.

Jerry
A good idea, but it won't happen if you're the only one supporting it. Develop allies!

Hope this helps.

Switching Topics at Conference Presentations

2011-10-13T11:37:00.000-07:00

My problem-solving letters seem to be very popular, so I'll continue this series whenever I have an interesting situation to discuss. Today, it starts with a letter from a writer colleague, let's call him Edgar.

Edgar's Letter
This weekend I'm presenting at a conference.

This morning I got a revamped schedule and suddenly I'm doing a break out session on "Coping with Foreign Withholding Taxes."

I'm in a bit of a panic because I've spent the last three months putting together a totally different presentation about "Working with Translators." Nothing like giving a presenter last minute notice. :}

Problem is, I have zero experience with foreign withholding taxes. I keep thinking I need to look into it, but have never had the time. If anyone has experience or thoughts that I could share at the conference I could really use some help.

Jerry's First Thoughts
This is an excellent example of a person offering a solution idea, rather than a problem statement. Edgar is asking for information on foreign taxes, presumably to help him cobble together a last-minute talk on the subject. In other words, he's already decided that he has to solve this problem by giving in to the organizers' totally unreasonable demands.

If he does that, his presentation will merely reveal him to be a fake, a pretender, not the real expert people at the conference would have a right to expect. In the long run, that's only going to tarnish Edgar's reputation as a professional, so I recommended a different approach altogether.

Jerry's Reply
Edgar, I sympathize with your predicament. In half a century of presenting at conferences, something similar has happened to me twice.

The first time, I didn't know how to handle it. I bungled around trying to wing it on the new topic. (I knew a bit about it, but probably not as much as some people in the audience, and in any case, I wasn't prepared.) I looked fake, and/or stupid, and news in our profession travels fast. Especially bad news.

Some years later, the same thing happened to me. This time, I knew what do do. I came to the session room a few minutes before the start time. As people arrived, I warned them that the announced topic had changed. But most people came just at the last minute, so they didn't hear my warning.

I gave them a few minutes to settle. Then I said, "The topic you see in your program is 'Coping with Foreign Withholding Taxes.' However, four months ago, when I agreed to do this session, I was told the topic was 'Working with Translators.' So, I have prepared on that topic for four months, but I haven't prepared at all for the Foreign Taxes topic. In fact, I know virtually nothing about that topic. So, if that's what you want to hear about, this isn't the place to hear it."

I went on to say, "If, however, some of you are interested in Working with Translators, stick around and I'll make my presentation."

Most of the people actually stuck around, and liked the presentation. If my topics had been like the two you mention, I might have said, "I assume you came here today because you're interested in doing business overseas. One way to help that happen is to handle the taxes wisely, but another way is to obtain good translations of your writing. After all, if you have no overseas business, you won't have any foreign taxes. So, this presentation could serve your purposes after all, especially since there are no other presentations on translations."

I may also have said (I don't remember, but I was younger and more impetuous then), "If you're unhappy about this last-minute switch, you might want to tell the conference organizers about your feelings. It won't help to tell me, as I had nothing to do with it."

References

I hope this story helps you a little. It's the best I have to offer.

If you'd like to learn more about my approach to solving problems such as this last-minute switch, you might want read one or more of my books, such as The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully; More Secrets of Consulting: The Consultant's Tool Kit; and Are Your Lights On: How to know what the problem really is.

Links to each of my books can be found on my website: http://www.geraldmweinberg.com

If you enjoyed this little essay, please sign up to come back for more.

Thanks,

Jerry

Moving Through Molasses

2011-10-09T23:28:00.000-07:00

Here's a letter I recently received from Agnes, one of my writing colleagues. I think it illustrates yet another one of the indirect changes arising from the changes in publishing technology. Here's the letter, followed by my response. (Edited, of course, to protect identity.)

The Letter

Currently I feel like I'm moving through molasses, going incredibly slow, and not getting anything done. I guess I've been feeling like that all year, since I began epublishing a year ago.

I've been annoyed with myself, because this past month, I've only gotten one chapter written on my new novel. I haven't got another novel in print yet though it is up electronically, and I've only gotten one more novel up on Smashwords and Pubit and not on Amazon yet. Blah. It's a strange feeling, like I'm just not moving at all.

But when I look back over the year as a whole, I have to think that feeling of not getting anything done is an illusion. Since last October, I've published electronically a dozen books and half-a-dozen short stories. And put eight of those books out in print.

What I can't figure out is why it feels like I'm not getting anything done at all, when if fact I'm being somewhat productive. It's just crazy.

My Response

Not crazy, Agnes. Just unfamiliar. I've been feeling the same way ever since I started publishing electronically, and I've put up over forty books.

I think, for me, it's not experiencing the various "mileposts" of traditional paper publishing: the letters back and forth from and to various editors, the contract, the galleys, the phone calls, the page proofs, more letters, the cover designs, ...

I didn't realize it all these years, but these mileposts made me feel I was accomplishing something—though of course I now realize they meant just the opposite. They were all delays, preventing me from seeing my work "in print."

Now, once I finish my part(s) of the publishing job, it's finished. Done. Ended. And on sale and earning royalties. And I'm left with the feeling I haven't really done that much.

One thing that helps me is watching the sales figures climbing every day. I know some of our colleagues say you shouldn't do that, but it takes less than five minutes a day. Those five minutes give me a sense of accomplishment, a sense that motivates me to do more work that day.

Anyway, that's the way it is for me. Perhaps it's something similar for you.

If you enjoyed this little essay, take a look at Weinberg on Writing, The Fieldstone Method. You can find it listed at these stores

• Barnes and Noble bookstore: http://tinyurl.com/4eudqk5

• Amazon Store: http://amazon.com/-/e/B000AP8TZ8

• Apple Store: http://apple.com

• Smashwords Store:

Medium-number Systems

2011-10-05T09:10:00.000-07:00

A reader recently wrote asking about Medium Number systems. I thought other readers of An Introduction to General Systems Thinking might be interested in my answers to his questions:

Reader: I'm interested in learning more about the "Law of Medium Numbers" described in your book of An Introduction to General Systems Thinking. I feel the "Law of Medium Numbers" sheds light on many puzzles I have run into in dealing with nature and society. Thus I wonder whether I may ask you a few related questions? -

1. As I searched the literature trying to learn more about this subject and the "Law of Medium Numbers", I was surprised by how little I could find. I wonder whether I was not doing right searches or you may have more insights into this?

Jerry: It's not a popular subject with many scientists, because it shows how science—though amazingly successful in some areas—it's awfully limited in dealing with some of the most interesting problems. As someone pointed out years ago, "Physics is merely the study of those systems for which the methods of physics work."

Reader: 2. I wonder whether the "Law of Medium Numbers" might imply a kind of defiance of classical Western science and technology (which emphasize certainty and perfection)?

Jerry: That's well put. We'd like things to be different, but they aren't.

Reader: 3. Perhaps human individuals are medium number systems and thus may explain why we all have certain limitations (in other words, no one is perfect). So medium number systems may also be called imperfect systems. Am I right on this?

Jerry: Precisely right, except it's not the systems that are imperfect, but our understanding of them. You can see this idea worked out in detail in my book on software testing: Perfect Software and Other Illusions about Testing. It's extremely popular among software testers. They use it to explain to their customers what amounts to the Law of Medium Numbers applied to software. And, a few software developers have shown violent reactions to the claim that perfection is simply not possible.

Why English Will Never Be 100% Automated: Example

2011-09-21T11:11:00.000-07:00

One of the nice features of the Kindle eBook service is they way they copy-edit some of their better-selling books. This can be a particularly important service for print books that have been scanned to make eBooks. For instance, Amazon recently wrote about my Kindle book, An Introduction to General Systems Thinking:

Typo issues exist that may have been caused by an Optical Character Recognition (OCR) problem. Few examples are given below:

loc 1561 - "T call them" should be " I call them".
loc 2946 - "But 1 still can't" should be "But I still can't".
loc 3351 - "Shasta the liger" should be "Shasta the tiger".

Please look for the same kind of errors throughout the book.

The first two instances are common OCR (Optical Character Recognition) errors: "T" for "I" and "1" (the numeral) for "I" (the capital letter).

The third example is a not quite so common OCR error, "l" (the letter) for "t". And, in this case, it's not an error at all.

The sentence in question was:

We do not often have our excessively sharp view of the world challenged by phenomena like Shasta the liger at the Salt Lake City Zoo, whose father was an African lion and whose mother was a Bengal tiger.

Still, the sentence contains a more subtle error: the failure of the author (me) to account for the mental state of the typical reader, for whom the term "liger" may be unfamiliar. (Even though it is found in at least 16 on-line dictionaries.)

I corrected this much more subtle error by redrafting the questionable sentence as:

We do not often have our excessively sharp view of the world challenged by phenomena like Shasta the "liger" at the Salt Lake City Zoo, whose father was an African lion and whose mother was a Bengal tiger.

As I dealt with this situation, I kept sighing and thinking, "English will never be entirely automated."

And then I took a deep breath and thought, "I suppose I prefer it that way."

How about you? Would you like English to be entirely clear and logical?

An Introduction to General Systems Thinking

Downgraded to Testing

2011-09-17T22:40:00.000-07:00

Here's a letter I got from a friend overseas. I've altered any identifying information, for obvious reasons. I'm going to intersperse some comments as if I were conversing with Nicolai face-to-face.

Nicolai's Letter
One thing I still like to know from you about "Perfect Software and Other Illusions About Testing". Are there metrics or measurement criterias with which you can measure the success of Testing in the software development life cycle (SDLC)?

I am in a struggle with my employer to change my position from a system developer (am working for the auto parts industry / manufacturing planning and execution) into a software tester. I made that decision after I recognized that this job much more fits to my personality type than doing the implementation.

Jerry
That recognition is an excellent starting point for solving your problems. Many people don't really know consciously what they really would like to do.

Nicolai
But let me come back to my main concern nowadays. My problem now is that in my country and especially in my company, this issue of Testing is new. My boss's understanding of it is low and hence he wants to reduce my salary around 10%.

Jerry
Sorry, that's not why he wants to reduce your salary. That's his excuse for taking advantage of your wish to change jobs. He simply sees an opportunity to save some money at your expense. Yes, if he understood anything about testing, he should raise your salary by 10%—or more.

Nicolai
That's in contrast with the huge losses we have because of NOT using Testing at all in our processes.

Jerry
Oh, my. Your company is at Level 0 when it comes to Testing. Oblivious! That is definitely not the place to be if you wish to make a career, long or short-term, in Testing.

Nicolai
Anyway I will not stay long there anymore.

Jerry
That's the wisest thing you've said so far.

Nicolai
I will try to setup my own company (industrial import export trading consultancy).

Jerry
That's an ambitious goal, and probably long-term. You cannot afford to stay any longer in this unbelievably bad company with this even more unbelievable manager.

Nicolai
But in the meantime I have to feed my family and I need an advice from how I can measure the success of Testing. Based on such criteria, I can improve my salary negotiation and make Testing much more tangible to everyone even myself. Once I have the criteria or indicators, I can make a some percent part of my salary depending on the success of implementing Testing into the SDLC. I think that is fair enough.

Jerry
Your boss has demonstrated he has no interest in "fair enough." And no interest in your career or your family. Your approach is all wrong. You should first find yourself a job in an organization that already values Testing, at least slightly.

In my experience, an organization like yours is never (at least in your working lifetime) going to value testing enough to value you, or pay you what you're worth to them. Nor will it be a good place to learn the profession. All you will learn is what I'm telling you now: that is, you shouldn't stay in this job a moment longer than you must in order to see that your family is fed. (For example, if your wife works, see if you can simplify your finances so you can live on her income, at least for a short time.)

But, in any case, you should immediately begin searching for a new job, in a much more compatible place. (And do it without letting anybody know. The kind of boss you have will not react well to news that you're seeking a new position. Let him know when you're saying goodbye, when you've already been hired by the new place.

Nicolai
What would be such indicators of a successful integration of Testing into the software development life cycle (SDLC)? I know you use the FFR, but this says something about the quality of the software development team. What would be indicators that say something about the quality of the software test team?

Any hints from you are very welcome.

Jerry
What you need now is one or more ways to put a cost on the software errors that are already reaching your users. (For example, you can use methods described in Quality Software series of eBooks—particularly Volumes 3 and 4: How to Observe Software Systems and Responding to Significant Software Events.)

Use these methods to arrive at average and extreme costs of each software bug that leaves your development group. And a count of how many bugs you ship with how much software. Then you can produce a report that says, "If our Testing is X% efficient at finding bugs, and if our developers are Y% efficient at fixing them before release, then we can expect to save Z-dollars by having a Testing group."

If you really do no Testing now in your SDLC, you can expect Z to be a very large amount. (And if it's not a very large amount, then Testing is really not important there, and you shouldn't be working there.)

Even if you're already in a Testing group, you should make such measurements, so you can get the support you need. And be appreciated.

I hope this helps.

References

Responding to Significant Software Events

How to Observe Software Systems

Change Artist Challenge #8: Applying The Principle of Addition

2011-08-26T16:50:00.000-07:00

The peculiar vanity of man, who wants to believe and who wants other people to believe that he is seeking after truth, when in fact it is love that he is asking this world to give him. - Albert Camus

Satir's Principle of Addition says that people change behavior by adding new behaviors, rather than getting rid of old ones. The reinforced behaviors are done more often, leaving less and less time for behaviors not reinforced.

The Challenge
Your challenge is to practice giving affirmations for behaviors you wish to increase. This can be in the form of an e-mail note, a card, a phone call, a brief office visit, a comment in the corridor. It must be done, however, directly to the person, not through some third party.
Each and every day, give one affirmation to one person.

Experiences
1. This forced me to pay attention to what people were doing.

2. This was really hard! Something deep inside me got caught in my throat when I started to form an affirmation of someone. It's a good thing I had a support group to help me figure out where that came from. I'm still not very good at it, but I can get the words out.

3. I thought I was already doing this, so it would be a really easy assignment. It turned out that nobody recognized when I was giving an affirmation, because I always cut the corners off it by some little joke, or discount.

4. I'm pretty good at this, in person, so I decided to start sending little cards to people who had done something that helped one of my change projects. Boy, was I surprised at how delighted they were! Something about a card made them really sit up and take notice; maybe it showed that I was thinking of them when they weren't present, and I took that little extra time to do this in a way that wasn't the easiest (e-mail). Maybe that made it seem extra important.

5. I made a list of people I ought to affirm, and made five copies, one for each day. I would check each one off the day's list so I would have a measure of how well I was doing. My goal was to be able to do everybody in one day by the end of the week. There were 14 people on the list, and my scores for the five days were 4, 7, 6, 11, 14. I was very proud of myself, and on Saturday I showed the list to my Will (my husband) and explained the assignment. He read over the list and told me I had forgotten someone. I was devastated: What good was a perfect score if it wasn't the whole list? But I couldn't for the life of me figure out who was left off. On Sunday, in church, I was still thinking about it and not really listening to the sermon. Will leaned over and whispered in my ear: "You." At our church, some of us stay after the service for a discussion of the sermon. God must have been watching over me when He sent the sermon that day because the subject was "Love thy neighbor as thyself." I understood that if I didn't love myself very much, loving my neighbor as myself didn't mean very much. I'd say I had a religious experience because of this exercise.

Source
These challenges are adapted from my ebook, Becoming a Change Artist, which can be obtained from most of the popular ebook vendors. See my website <http://www.geraldmweinberg.com> for links to all of my books at the major vendors.

We're not so smart, or strong

2011-08-22T23:24:00.001-07:00

Finally, the orangs get a chance to have fun and make decisions.

And Apple has a great new market.

Will these primates knock out another Shakespeare play?

Amplify’d from kotaku.com

These Orangutans Play with iPads

Orangutans, it turns out, love the iPad and its games just as much as some humans do.

A budding program at the Milwaukee County Zoo is working to place iPads into the giant, gentle palms of their orangutans. Two of the zoo's orangutans already look forward to weekly sessions with an iPad. They even have favorite apps, shows and games, but they haven't yet been given free rein with the Apple device because keepers worry they might get frustrated and simply snap one in half.

"One of the biggest hurdles we face is that an orangutan can snap an iPad like you or I could rip cardboard," said Richard Zimmerman, executive director of Orangutan Outreach, which hopes to extend Milwaukee's iPad enrichment program to zoos around the country. "Even the little guys like Mahal are incredibly strong. A big male could take it apart in about five seconds."
Read more at kotaku.com

See this Amp at http://amplify.com/u/a1bqhb

Size Does Matter in Space!

2011-08-20T21:26:00.001-07:00

Size matters, but in space, it's the smaller the better.

We need more breakthrough thinking/engineering like this.

So, read all about it.

Amplify’d from singularityhub.com

Computer Chip-Sized Spacecraft Will Explore Space In Swarms

by Peter Murray August 15th, 2011 | Comments (2)

We knew to expect a paradigm shift with the end of the space shuttle program, but this is ridiculous. Mason Peck and his group of forward-thinking engineers are taking NASA’s slogan of Faster, Better, Cheaper to the extreme. Their spacecraft will cut down travel time to Alpha Centauri from thousands of years to just a few hundred, and instead of the $1.7 billion it takes to build a space shuttle, Peck’s ships can be built for an amazing $33.

I might mention that there’s no room for astronauts. In fact, if one were to try and board these spacecraft they would crush it.

The spacecraft are called Sprites and they weigh about 10 grams each. Integrated circuits 3.8 cm on a side, they’re literally spacefaring computer chips. This past May the space shuttle Endeavour brought three Sprite prototypes to the International Space Station. Fixed to the station’s exterior, they are currently in the early days of a two year test to see how they stand up to the harsh elements of space.
Read more at singularityhub.com

See this Amp at http://amplify.com/u/a1bmde

Change Artist Challenge #7: Being Fully Absent

2011-08-18T23:19:00.000-07:00

Being Fully AbsentWhoever is in a hurry shows that the thing he is about is too big for him. - Lord Chesterfield

During the Great Plague of 1666, Newton was forced to go home for a holiday when schools closed in London. While idling under a tree, he got the basic idea for his Theory of Universal Gravitation.

During the heyday of telephone exploitation (1877), Alexander Graham Bell got married and took a yearlong honeymoon in Europe! While there, he had his grand vision—not for the telephone, but for the telephone system.

So much for not being able to leave a project for vacation! As your powers as a change artist grow, it's easy to get the grandiose idea that the world can't change without you. This challenge is a challenge to that idea. It's also a way to trick you into taking care of yourself.

The Challenge
Your challenge is to take a week away from work, and when you get back, notice what changed without you being there. You must not do anything about your change artist work for a whole week, but notice what thoughts come into your head, or what apples fall on it.
Do you think you can't do this? Then you have a different assignment, suggested by Wayne Bailey: "If you're going on a week-long vacation and feel the project cannot do without you, then take a two-week vacation."

Experiences
1. We took two weeks and went to Hawaii. It was our first vacation in seven years—really since our honeymoon. I'd always dreamed of a Pacific island paradise, and we found it. The first few days, Shanna and I drove all over the Big Island like tourists. It was interesting, but it wasn't the vacation of my dreams. Then we just starting frolicking on the beach, eating, laying about in the shade, eating, really talking to each other, eating, swimming, and eating. After about seven days of this bliss, I woke up early one morning and realized that though I hadn't consciously thought about work at all, I suddenly had a complete vision of how our process improvement program had to be restructured. Shanna was still asleep (it was real early), so I slipped out for a walk on the beach. When I got back about two hours later, I had the entire thing worked out in my mind. I didn't even have to write it down—it was so clear that I knew I couldn't forget it. Then I put it out of my mind and enjoyed the last three days of our vacation in paradise. When I got back to work, I had a new and revitalized organization. More important, I had a new and revitalized marriage.

2. I decided to spend a week hiking a segment of the Appalachian Trail. I hadn't done any backpacking for a couple of years, so I had to take out all my equipment, replace some of it, and reconsider everything. While doing that, I realized that I needed to do the same thing at work. I was so eager to get started that a little voice inside me said to forget the hike and get back to work. But I resisted. I was able to use the hike—even though it rained most of the time—as a metaphor for the changes I had to make at work. Come to think of it, that was probably because it rained all the time.

3. I stayed home and played solitaire, did jigsaw puzzles, and cleaned the house. I also rearranged my thoughts. Thank you for this assignment.

4. I went to Spain, where I could refresh my school Spanish. I spent a week in Madrid and a week in Barcelona, with a few side trips into the country. Perhaps it was living in another language for two weeks, but I didn't think of work at all. When I came back, I discovered that they had gotten along very well without me, and were eager to show me some of the nifty things they'd accomplished. At first I was depressed, thinking that I wasn't as essential as I had thought. Then I was elated when I realized that I had done a good job of preparing them to keep improving things when I wasn't there. I guess that's really the change artist's job, isn't it.

Persistence in Problem Solving

2011-08-12T21:07:00.000-07:00

I write about and teach about problem solving. I also consult on the topic. Sometimes, when one of my clients is stuck on a problem, I tell them I have a sure-fire solution method:

Write it down, seal it in an envelope, put it in a safe place, and open it after 50 years. Then, if it's not solved itself by then, seal it in another envelope for 50 more years. It's sure to be solved by then.

Well, I'd never actually tried the method, but something special happened today that I just have to tell. The story began, if I remember correctly, in 1949, more than 60 years ago. I was taking a bookkeeping class in high school, and on the first day, the teacher started off by saying:

"Bookkeeping is the only word in the English language that has 3 consecutive double letters."

Being a wise-ass young kid, I raised my hand and said, "I know another one."

Startled, she asked, "And what's that?"

"Bookkeeper."

That got a few laughs from the students, and put me on her s-list for two semesters.

Still, after all this time, that's about the only thing I remember from that bookeeping class--mostly because I kept seeking another 3-double-letter word, on and off for all that time.

Well, today I was working on a mystery novel with some prison scenes, and I came up with the kind of word I was seeking. It was prison slang for the warden:

Crookkeeper.

(Dani says it could also be the name of the person who guards shepherds' equipment.)

MORAL: Virtually any problem will be solved if you work on it for 50+ years. So, never give up, but sometimes delay.

Problem Definition

If you like solving problems, and don't always have the patience to wait 50 years, you may shorten your solution time if you start with a better problem definition. You'll be able to do that if you read one or more of the books pictured here. Take a look at http://www.geraldmweinberg.com

Addendum
I guess I should also post a contrasting story about the quickest problem solving effort:

About 5 seconds after I posted this blog, I got a tweet from "@perze" saying:

Hello Mr. Weinberg i don't want to sound like a wise-cracker but "bookkeeping" was misspelled in your last post.

Good for your @perze!

Fixing this post also gave me a few seconds to come up with a couple more 3-double-letter words:

1. When my Aunt Minnie used to visit, my father gave me the task of keeping my cousin Larry out of his sight. In doing that, I was the schnookkeeper.

2. When fishing, I was put in charge of guarding the tackle, so I was the hookkeeper.

3.

What's Wrong with Agents as Publishers?

2011-08-10T10:38:00.001-07:00

Here's a guy who knows the story from all sides, and is not afraid to tell it like it is.

Amplify’d from theworstbookever.blogspot.com

Should Agents Publish? (Writers Beware!)

AGENTS, ERR... PUBLISHERS...?

The answer to this question is a resounding don't even try to argue with me NO!

How can I say this when so many have neat little answers? Because it is like having your lawyer be your judge. In the last few months I have seen the book agent turn tail and not only abandon all ethics of their business, but chase the money like so many drowning rats. Am I being to harsh? Maybe, but I have good reason.
Read more at theworstbookever.blogspot.com

See this Amp at http://amplify.com/u/a1aiwt

Change Artist Challenge #6: Being Fully Present

2011-08-05T20:36:00.000-07:00

It always seems to me that so few people live—they just seem to exist—and I don't see any reason why we shouldn't LIVE always... - Georgia O'Keeffe

In order to be a successful catalyst for change, you must learn the art of being fully present. To be fully present, you must:
1. Pay full attention to the speaker.
2. Put aside any preconceived ideas of what the speaker is going to say.
3. Interpret descriptively and not judgmentally.
4. Be alert for confusions and ask questions to get clarity.
5. Let the speaker know that he/she has been heard, and what has been communicated.

Here are a number of common hindrances to being fully present:

• Ignoring: lack of attention (looking elsewhere, fidgeting), boredom, disinterest, pretending to listen

• Selective listening: hearing only parts

• Sidetracking: changing the subject (without proper transition); telling your own story; making light of, with inappropriate humor

• Evaluative listening: agreeing or disagreeing before the explanation is finished

• Probing: asking too many questions (from your frame of reference) with little sense of the person

• Interpretative listening: explaining what's going on based on your own motives and behavior

• Advice giving: offering solutions; focusing too much on content

The Challenge
Your challenge is to pick one habit that keeps you from being fully present, and focus on reshaping that habit in all your interactions.

Experiences
1. I decided to try going through a meeting without telling any jokes. I didn't actually make it all the way, but they seemed to appreciate my joke more, when I finally told it.

2. I didn't really know what to do, as I thought I was a good listener. I got a support person who told me that I should stop reading my mail during meetings. That really surprised me, because I thought myself so good a listener that I could read mail and listen at the same time. Besides, it kept me from interrupting. My supporter told me that even though I might be hearing everything that was said, my reading made it look like I wasn't paying attention, or at least didn't care what was being said.

3. I'd read about not giving solutions during review meetings, but I was strongly opposed to the idea. It just didn't make sense to me. But, since I had to do this assignment, I decided to try doing one review without offering any solutions. I did have two solution to offer, but the author came up with one of them a few minutes later, before I said anything about it. Actually, I guess it was pretty obvious, and if I'd said it, he probably would have thought I considered him stupid. I saved the other until after the meeting, and it was really appreciated. It seemed to be a pretty good review, actually one of the better ones I've ever attended.

4. I have to tell you that I'm known around here for being the person who can get anything out of anybody with my penetrating questions. I decided to try a new tactic. Whenever I found myself thinking of a neat question, I caught myself and asked, instead, "What else do you want to tell me?" I got just as much information as I ever get, so maybe I'm not such a great questioner as I thought. Or maybe I'm greater—I can do it with just one question!

5. I looked at whoever was speaking. Every time. I had been missing a lot, not seeing facial expressions and posture. I think I'll do it again.

Source
These challenges are adapted from my ebook, Becoming a Change Artist, which can be obtained from most of the popular ebook vendors. See my website <http://www.geraldmweinberg.com> for links to all of my books at the major vendors.

Make sure of your writing heritage

2011-08-01T20:58:00.001-07:00

Please do not ignore this essay. Please.

Amplify’d from writer-in-residence.blogspot.com

Estate Planning

Editor Robert Runte is sharing an important reminder for us authors: we need a will.

One topic that most writer's advice columns never get around to addressing, but which is fairly crucial, is estate planning. Yes, I know, you are immortal and are never going to get sick, let alone die, but let us for the sake of argument talk about a couple of simple steps to save one's family a fair bit of trouble, and to perhaps ensure one's literary immortality.

The Will

First, write a will. No one likes to think about wills much, and certainly don't feel it's something they need to address today...sometime in the indefinite future will be fine, they think. But, stuff happens. So, right now, make an actual appointment to draw up a will. And then, in addition to the usual content, put in a couple of clauses outlining who gets the literary property, and what they should do with it.

There are four issues here: (a) who gets the royalties (if any) from the work; (b) who has artistic control over one's published work; (c) what is to be done with any unfinished manuscripts that are left lying around after one is gone; and (d) what is to be done with one's online presence.
Read more at writer-in-residence.blogspot.com

See this Amp at http://amplify.com/u/a1a5k5

A Universal Starting Point for Problem-Solving

2011-07-29T15:27:00.000-07:00

By popular request, I'm going to hold my next Change Artist Challenge until next week to give some of my readers a little more time to catch up.

This essay should also be helpful to change artists, who often have to start their work by defining or redefining a problem that's presented to them. It's adapted from Chapter 5 of Exploring Requirements 1: Quality Before Design.

How can we reduce the great variety of potential starting points to a single solid platform for exploring requirements? A possible solution is to regard every design project as an attempt to solve some problem, then reduce each starting point to a common form of problem statement.

A problem can be defined as
a difference between things as perceived
and things as desired.

[For a full discussion of problem definition, see Donald C. Gause and Gerald M. Weinberg, Are Your Lights On? How to Know What the Problem Really Is.

Figure 5-1. A problem is best defined as a difference between things as perceived and things as desired.

This definition can serve as a template measuring each idea for starting a development project. If the idea doesn't fit this definition, we can work with the originator to universalize the idea until it does.

Universalizing a Variety of Starting Points
Let's see how this universalization process can be used to reduce six different starting points to a common form of problem definition.

Solution idea
Perhaps the most common starting point is thinking of a solution without stating the problem the solution is supposed to solve. In other words, the idea doesn't say what is perceived (and by whom) and what is desired, so it doesn't fit our definition of a problem. Here are a few examples we've experienced.

1. A marketing manager told a systems analyst, "We need sharper carbon copies of our sales productivity report." Rather than immediately begin a search for a way to produce sharper carbons, the analyst asked, "What problem will sharper carbons solve for you?" The manager explained that the carbons didn't make very good photocopies, so the salespeople had trouble reading them. "So," the analyst confirmed, "you need one clear copy for each salesperson, and you're now making multiple copies of the report we give you?" Eventually, through such give and take, the problem was redefined as a need to provide timely and clear comparative information to a sales force of four hundred—something readily accomplished by slightly modifying an existing on-line query system. The final design didn't have sharper carbons. It didn't have carbons at all. Not even paper.

2. In another case, a university dean said, "We need a way to attract more students." The dean never said why they needed more students, and each faculty member hearing the statement formed a different idea. Some thought "more students" meant getting more outstanding students. Some thought "more students" meant being able to support more teaching assistants in certain departments. Still others thought "more students" meant the dean wanting to fill the vacant dormitory space.

After arguing for months about the best way to get more students, the faculty finally learned what the dean really wanted: to create the impression in the state legislature that the school was doing a higher quality job by increasing the rejection rate of applicants, so the university appropriation would increase. Once this goal was understood, the faculty approached a solution in several ways, none of which involved an increase in student enrollment.

Technology idea
Sometimes we don't have a problem in mind, at all, but literally have a solution in hand: a solution looking for a problem. When tearing off those perforated strips on computer paper, have you ever felt there ought to be something useful to do with them? The perforated strips are the solution, and the problem is "What can we use them for?" After thirty years of searching, Jerry bought Honey, a German Shepherd puppy, and suddenly he discovered the problem his solution was looking for. Computer paper edges, crumpled up, make perfect litter for puppy nests!

When a new technology comes along, it's often a solution looking for a problem. The Post-It™ note developed by 3M is a conspicuous example. The semi-stickiness was originally just a failed attempt to produce an entirely different kind of adhesive. Instead of simply discarding it as another failed project, the 3M people thought of problems for which such semi-adhesive properties would provide a solution. They created Post-It™ notes, but the solution-to-problem process didn't stop there. As soon as Post-It™ notes appeared in offices, thousands of people began seeing problems they would solve.

Some of the high-technology companies we work with are dominated by this kind of solution-to-problem starting point. In effect, their problem takes the form of the following perception and desire:

Perception: We own a unique bit of technology, but others don't want to give us money for it. For example, a chalk company buys rights to a new vein of chalk that has exceptional purity and strength. To most people, however, chalk is just chalk.

Desire: Others will pay us a great deal of money for the use of this technology in some form. For instance, if the company can create the idea of Superchalk in the public mind, the unique purity and strength become an asset of increased value.

Such a problem statement allows the technology to become a kernel around which many designs can be built. Without it, technology firms often make the mistake of believing that "technology sells itself." Although this slogan may be true in certain cases, usually it's an after-the-fact conclusion. Want to turn a solution into a problem requiring it? Ordinarily, you'll need an enormous amount of requirements and design work. For example, how will you make teachers believe they can't really teach well without Superchalk?

Simile
Many product development cycles start with a variety of metaphorical thinking—a simile, or comparison, as when someone says, "Build something like this." Although the customer may emphasize "this," the job of the requirements process is to define "like."

For instance, Maureen, the leader of a software project, told her team she wanted a new user interface "like a puppy." "First of all," she elaborated, "people see a puppy and are immediately attracted to it. They want to pet it, to play with it. And they aren't afraid of the puppy, because even though it might nip them, or even pee on them, puppy bites aren't serious injuries, and puppy pee never killed anyone. Also, you can't really hurt a puppy by playing with it."

Although the team couldn't yet build a system with this requirement, playing with the simile did inspire them to ask probing questions. "How about housebreaking and obedience training for the puppy?" a teammate asked.

Maureen thought a bit, and said, "Yes, the interface should be trainable, to obey your commands, so it becomes your own personal dog."

"Okay," asked someone else, "will it grow up to be a dog, or remain a puppy?"

"That's easy," said Maureen. "It will stay a puppy if you want it to be a puppy, but if you prefer, it will grow up to be a real working dog doing exactly what you say."

"What kind of working dog?"

"A watchdog, for one thing. It should warn you of dangerous things that might happen when you're not paying attention."

Someone else got into the spirit by asking, "What about a sheepdog? It could round up the 'sheep' for you, and put them safely in the pen. And guard them from anyone stealing any."

By this time everyone was involved, and the requirements process was running like a greyhound, though not necessarily in a straight line, as when someone asked, "How about fur? Should it be a longhair or a shorthair?" Nobody could figure out what fur meant for an interface, though the question did lead to an extensive discussion of touch screens and other interface hardware they had never previously used. Eventually this tangent was clipped by someone observing, "Our tail is starting to wag the dog."

The simile is excellent as an idea-generation tool, but eventually the requirements group has to groom their ideas into prize-winning form, which requires some idea-reduction tools. You know when the simile has become a bit dog-eared when you can no longer make fruitful connections between it and your product. It's important, though, to keep it going a bit past the point where it becomes ridiculous, just to be sure you've generated enough ideas.

Norm
Many people do not consider themselves metaphorical thinkers, believing they think more concretely. In the requirements process, they would more likely say, "Here is a chair. Design a better chair." or "Here is ordinary chalk. Design a superchalk." In fact, the norm is also a metaphor, seeming literally "close" to the thing desired. The great danger of using a norm is the constriction on our thinking once we identify what would almost satisfy the customer.

Another great danger is making one big leap in logic to the end result. Instead, starting with a norm and working by increments tends to protect us from the colossal blunder. The Wright brothers, for instance, were bicycle builders, and they used many of the norms from bicycle construction to create their success at Kitty Hawk.

A third danger is starting with the wrong norm, which could prevent us from making a great leap forward when one is possible. Orville and Wilber Wright did use a rail to launch their plane, but they didn't become the first heavier-than-air fliers by putting wings on a locomotive (Figure 5-2).

Figure 5-2. Don't let the norm dictate the form. If the Wright brothers had been train builders, they might have specified a plane that looked like this hybrid, which might have been on the right track, but would have had a hard time getting off the ground.

Mockup
Suppose we agree to use a chair for a norm. Unfortunately, your mental picture of a chair may be very different from mine. A mockup is a way to protect against this ambiguity by providing an actual scale model of a product. Moreover, we can benefit by using the mockup to demonstrate, study, or test the product long before the product is actually built.
A mockup serves as a norm, when no norm exists, or when none is available. As such, it has all the advantages and disadvantages of a norm. It also has the advantage and disadvantage of being a fantasy product. When we use a mockup, we aren't restricted to what exists, but on the other hand, we can easily mock up a product that could never actually be built.

In printing, and in computing, for example, the mockup is often in the form of a layout of printed matter, or material on a screen. The customer and users can point to the layout and say, "Yes, that's what I want," or "No, what's this doing here?" What we are actually testing with the mockup is the customers' emotional responses—their desires. In effect, a mockup says, "This is what we think the product's face will look like. Let's see how you react to this!"

Name
Many ideas for design projects simply begin with a name: Create Superchalk. Build me a table, chair, pencil, clock, elevator, steering wheel, speedometer, or bicycle. Although the name provides a quick and common connection for all participants to grasp, names also come with a large baggage of connotations. As we've seen, each word is worth a thousand pictures, and each connotation of a name may introduce implicit assumptions.

For instance, Jerry spent thirty years searching unsuccessfully for a use for computer paper edges largely because the name itself narrowed his thinking unnecessarily. Our colleague Jim Wessel observed that his four-year-old daughter isn't so limited. She cuts these strips into smaller pieces and calls them "tickets." We would do well to emulate the four-year-olds who have little trouble making up names for objects lacking conventional ones.

Further Reading

The Exploring Requirements books can be obtained from a variety of retailers. Go to my website and chose your favorite source of books or eBooks.

Change Artist Challenge #5: Being The Catalyst

2011-07-23T21:13:00.000-07:00

Look abroad thro' Nature's range.
Nature's mighty law is change. - Robert Burns

Although change artists often work as prime movers, they more often work through understanding natural forces and creating slight perturbations of Nature. In this challenge, you will practice facilitating the change projects of others, using various ways of empowering from the position of catalyst. In chemistry, a catalyst is a substance that added to a reaction accelerates that reaction by its presence, without itself being changed by the reaction.

A human catalyst is someone who rouses the mind or spirits or incites others to activity with a minimum of self-involvement—in other words, by empowering others. For people to be empowered to change their organization, the MOI model tells us that the following ingredients are required:

Motivation
• self-esteem
• a value system and a vision held in common
• a sense of difference between perceived and desired

Organization
• mutuality of support, based on personal uniqueness
• a plan for reducing the perceived-desired difference
• a diversity of resources relevant to the plan

Information
• a systems understanding of what keeps things from changing
• an understanding of empowerment versus powerlessness
• continuing education appropriate to the tasks

Often, only a single ingredient is missing, but the person who doesn't know which one it is can feel completely disempowered. The recipe suggests which ingredient might be missing. A change artist who supplies that missing ingredient can catalyze change with minimal effort.

The Challenge

Your challenge is to facilitate other people's change projects, approximately one per week, for at least two weeks. You should attempt to be a catalyst, for change, not the prime mover for change. To be a catalyst, you should involve yourself

• as effectively as possible

• in the smallest possible way

• without depleting your capacity to catalyze other changes

If possible, use each ingredient of this recipe for empowerment at least once. Keep notes in your journal and be prepared to share learnings with the group you are catalyzing.

Experiences
1. A group in the shipping department asked me to help them run their planning meetings. I said I would do it if they enrolled two people in our facilitation class, and that after taking the class, they would work alongside me. After one meeting, they are now facilitating their own.

2. I led a technical review of the design of a very controversial project, and apparently I did a good job because I got three other invitations to lead difficult reviews. I did lead two of them, but I decided to try being a catalyst on the third. I told them I wouldn't lead the meeting, but I would play shadow to a leader of their choice and we would switch roles if their leader got in trouble. She didn't.

3. One of my groups wasn't using—or even attempting to use—the new configuration control system. Ordinarily, I would have ordered them to use it, with threats of reprisals. I thought about the minimum thing I could do—with no force and no blaming—to get them moving. I decided to call them in for a meeting and give them the problem of how to get them moving. They told me they just didn't have time to switch their partially developed project to the new system. I asked them how much time they would need. They huddled and came up with a two-week extension to their schedule. (I had been afraid they would say two months.) Since they were off the critical path, I said they could have the two weeks, but only if they switched to the new system. They actually did the job in one week, and in the end, they made up four days of that—partly, at least, because of using the better tool. I've now used this consultation method several more times. "What would you need to give me what I need?" turns out to be a great catalyst. I like being a catalyst much more than being a dictator.

Source
These challenges are adapted from my ebook, Becoming a Change Artist, which can be obtained from most of the popular ebook vendors. See my website <http://www.geraldmweinberg.com> for links to all of my books at the major vendors.

Change Artist Challenge #4: changing a relationship

2011-07-15T15:09:00.000-07:00

Your fourth challenge will be to undertake changing a relationship. The purpose is to apply some of your learnings about congruence and conflict.

The Challenge
Choose one relationship you have with another person that's not all you would like it to be. It could be a good friend with whom there's one thing that annoys you but you've suppressed it, or something you like that you'd like more of. It could be a work associate with whom you're not on the terms you'd like to be. Again, don't start by tackling the most difficult relationship you have. If you finish changing one relationship, you are free to do another, and another..., so don't worry that it's too small.

As before, find an interested change artist, or associate, or some willing person, meet with the person and explain the change you want to make. Seek assistance in planning how to go about changing this relationship—assistance with ideas, in checking your ideas, and possibly in practicing in a role play. Then carry out your plan with the actual person.

This challenge will especially give you a chance to confront the difficulties you have in the presence of strong (or potentially strong) emotions in others. After all, you won't know in advance how the other person will respond to your attempt to change the relationship. They might cry, or go into Chaos, or get involved in a conflict with you over it, or become incongruent in a variety of ways. How will you handle yourself in those situations? Will you fail to take a risk because you anticipate one of these reactions?

Experiences

1. I decided to get to know my boss better as a person, and not just as a "boss." I asked her to lunch. She was a bit taken aback, but once we agreed it would be Dutch treat, she was okay with it. We found out that we both have a passion for softball, but play in different leagues. That gave us a lot to talk about, and since then I've given her the benefit of the doubt when she comes out with some edict I don't understand.

2. I'm responsible for upgrading all the Mac software for my department, and one of the users has been a pain in the derriere for me ever since I got this job. I decided to sit down with him and ask him how he felt about the service he'd been getting. He said that people seemed to avoid him when he had problems, and he was pleased that I'd take the time to sit down with him. I was able to show him a few things that prevented trouble, and cured some things he hadn't even bothered to complain about. He's still a pain, but just in the neck, and I can deal with it. At least it's a little higher up. (smiles)

3. I have an employee who drinks excessively. I had been avoiding the topic because I didn't really know what to do. I paid a visit to our employee assistance program, and they gave me some booklets and some coaching. Next time he came in to work drunk, I knew what to do, and didn't pretend it wasn't happening. He had to confront the impact he's having on his job, and he's now working with employee assistance. He may not solve his drinking problem, but if not, I can handle it.

4. I did this a little backward. I decided to change a relationship back to what it was before. Grace and I worked together for a couple of years, and were very good friends. Then I took a transfer to a different project and moved to another building. I guess I was feeling guilty, like I deserted her—which isn't the way a good friend should behave—so I avoided seeing her or even calling her. I decided just to go over and pay her a visit, like we used to do when we were in neighboring cubes. She wondered where I'd been, and we're back to being great friends. All "her" feelings about me "leaving" were in my imagination.

5. I'd been playing golf with our hardware salesman for a couple of years—him taking me to his country club almost every Saturday. I never felt good about it, like it was somewhat unethical. So I told him that I couldn't play with him anymore unless I paid my way. He objected, saying it wasn't costing him anything, since his company was paying for it. I told him that was the point. He said okay. Now we still play golf, but I feel a lot better about it.

6. I'd been locked in a struggle with Harmon for almost a year over which CASE tool we should use in the organization. I decided to approach him from the point of view that our conflict was only helping those reprobates who didn't want to use any CASE tool. We made a pact that we would join forces to get some CASE tool going, somewhere. We actually flipped a coin to see who would help whom. I lost, so I swallowed my pride and helped him sell his team on using the tool he liked. Once we joined forces, they were a pushover. He was going to help me sell my team on the tool I liked, but by this time I like his tool just as well—actually a little better.

Reference

Remember, these challenges are taken from my book, Becoming a Change Artist.

I've wanted to put up a cover picture, but nothing I've tried seems to work with Blogger.

Readers Pay, but Kindle Doesn't Pay Authors

2011-07-12T12:58:00.001-07:00

One good reason many international readers should buy my books through Smashwords—save lots of money.

Amplify’d from davidgaughran.wordpress.com

Amazon Hold Back The Growth Of E-Books Around The World

Posted on July 11, 2011 by davidgaughran

Writers often wonder why the growth of e-books is so much slower in the rest of the world.

There are a number of reasons for that, but one big factor is the $2 surcharge that Amazon levies on all e-books in most international countries.

This charge is levied by Amazon, and kept by Amazon, and has nothing to do with taxes.

This charge is applied whether the user downloads e-books through their Kindle or not, and whether the user even owns a Kindle or not.
Read more at davidgaughran.wordpress.com

See this Amp at http://amplify.com/u/a17p1k

The future of book publishing

2011-07-07T21:43:00.001-07:00

Kris slices up yet another repetition of a stupid old prediction.

Masterful writing and thinking, as usual from Kris. If you're interested in the writing/reading business, you should follow her blog. Absolutely.

Amplify’d from kriswrites.com

The Business Rusch: Slush Pile Truths

Kristine Kathryn Rusch

Why am I calling Felten’s piece ridiculous? Aside from the fact that he says the same thing writers from places like NPR to The Daily Beast have been saying for two years, he shows no understanding of the book business whatsoever. If he actually gave the subject some thought and did a little research, then perhaps he would have come to a different conclusion.

His premise is pretty simple: without book publishers, readers won’t be able to find the good stuff in the middle of all the crap.

Jeez, dude. Those arguments were old one hundred years ago when reading ceased to be the right of the rich and well educated, and trickled down to the masses. Anyone ever wonder why we ended up with a divide between “high-brow literature” and “low-brow crap”? It was because the cognoscenti no longer controlled what people read, therefore the cognoscenti lost a great deal of their power, so the cognoscenti had to make up words to distinguish between the “approved” books and that stinky genre stuff.
Read more at kriswrites.com

See this Amp at http://amplify.com/u/a171n4

Change Artist Challenge #3: Changing Nothing is Doing Something

2011-07-03T11:25:00.000-07:00

Of course I am idle, but I am not idle by nature; I simply haven't yet discovered what I can do here... - Sophie Tolstoy

The purpose of the next challenge is to find out what's driving you to change things, and what happens if you don't respond to that drive in the usual way.

The Challenge

Next time you're part of a team or group effort, sit back, listen, and observe. Your job is not trying to change anything. (You're not trying to prevent change. If the others want to change something, just let it happen. Otherwise, you'd be trying to change what they're attempting to do.)

Take particular notice of your urges to change things, and what happens when you don't do anything about those urges.

Experiences

Here are a few experiences of other change artists who accepted this challenge to do nothing at all.

1. Wow! I couldn't do it! I lasted almost three whole minutes. I resisted the temptation to open the window, or to ask someone to do it. I resisted the temptation to move the flipchart so everyone could see it. I resisted the temptation to move over one seat to make room for a latecomer.

But when Jack stood up and grabbed the marker pen (AGAIN), I couldn't resist suggesting that someone else should take a turn. It was out of my mouth before I knew it! But I just HAD to say it!

2. (The same woman as the previous experience.) After my first miserable failure, I decided to try again, the next day. I got through the mechanics a lot more easily—the window and the flipchart and the chairs—and with somewhat more difficulty, I let Jack grab the pen again. I was on a roll, and I managed to keep it up for almost fifteen minutes. When I finally did say something about the direction the meeting was taking (I just didn't notice what I was doing), the other people reacted as if I was the President of the United States. They gave me their full attention, let me finish everything I had to say, and then did exactly what I proposed.

I think there's a clue there for me. (duh) I'm working on it, and I'm going to try this again.

3. I didn't think this would be very hard for me. I would just sit in the meeting and do what I usually do—keep my mouth shut and observe. I was doing a good job of this when all of a sudden I realized that I was changing things in my mind about once every thirty seconds. Then I said nothing about any of them, and I found myself getting angry that nobody else was doing anything about them.

Aha. Were they doing exactly what I was doing?

4. (The same man as the previous experience.) Armed with my new insight, I worked out a plan for the next meeting. I sat in my usual way, quietly fanning my smoldering anger and frustration. When I got to the proper amount of emotional heat—not so much that I wouldn't be able to control it—I said a sentence that I had written down and practiced: "Is there anything about this meeting anyone would like changed?"

The reaction was instantaneous, and the changes poured out. The rest of the meeting went very differently from our usual meetings, though I didn't say another thing.

5. This was a pretty boring exercise for me, so I had to do something to occupy my mind. I decided to try to observe emotional reactions, because I had always thought our meetings were rather flat and unemotional, but our consultant told me they weren't. I noticed lots of things that I never saw before. For instance, two of our folks were really suffering—I didn't know from what, so I asked them about it after the meeting.

Was that a violation of the assignment? If it was, I don't care, because I learned some things I had never even suspected before, and the quality of my relationships with two members of the team have gone up several notches.

The Meta-Challenge

Here's a challenge about the challenge:

When you take this challenge, I'd love to read about what happened and what you learned. Hundreds of readers would like this, too. Besides, it will probably do you much good to sit down for a few minutes and recall your experience. Good writing practice, too.
For more about Becoming a Change Artist, you can read the book and try the entire sequence of exercises.

Change Artist Challenge #2: Making One Small Change

2011-06-22T21:18:00.000-07:00

     I report a conversation with a colleague who was complaining that he had the same damn stuff in his lunch sack day after day.

     "So who makes your lunch?" I asked.

     "I do," says he.
     When I heard his response, I thought, "This is about the smallest, least difficult, safest, change I can imagine. As such, it makes a perfect test for beginning change artists, a way of "measuring" how difficult it will be for them to change anything.
     So, your next challenge will be to undertake a change project of your own, but to seek support in making this change. The purpose is to launch your career as a change artist by experiencing some of the theoretical learnings in the "real world," but in as small and safe a way as possible.

The Challenge
     Choose one small thing about yourself you want to change. Novice Change Artists tend to be too eager for their own good. If you want to eat a whole elephant, start with single bite. If you finish one change, you are free to do another, and another—so don't worry that it's too small.
     Find an interested change artist, or associate, or some willing person, meet with them and explain the change you want to make, and contract with that person for the kind of support you think you need to accomplish your change. Check with your supporter periodically to update him/her on your progress.

Experiences
     Let's examine a few instructive experiences of other change artists accepting this challenge to make one small change.

1. When I have a hot idea in a meeting, instead of blurting it out, I write a little note to myself and wait a couple of minutes. I noticed that about 60% of the time, somebody else comes up with essentially the same idea. Then, when I support the innovator, the idea has a very great chance of being adopted.
     I've increased the number of my ideas that get adopted, but I'm not getting credit for them. At least not directly. But several people have told me that I've really become a leader in meetings. This was a surprise, because I thought they would consider me a leader when I had the most ideas—and they didn't. My supporter explained that I seemed more "statesmanlike," more calm and more respectful of others.

2. I take a break every hour when I'm alone, or when I'm in meetings. This was really hard to do. I didn't want to interrupt anyone, but my supporter gave me some good suggestions about how to "test the waters" before doing it in a meeting.
     To my surprise, most people welcomed the breaks, most of the time. I learned that people (including me) often don't say what they want, and this has transferred to the practice of polling groups more often to find out how they feel about what's going on in meetings.

3. I posted hours when I would be uninterruptible, and hours when I would always be available for interruptions. At first, people didn't respect these hours, as they didn't believe I would really do it. I couldn't say no to anyone, so my supporter actually came into my office from 4 to 5 one day (the busiest time) and coached me on how to dispatch people to the posted schedule. This worked pretty well for me, but it was a strain for some of them. I then realized that 4 to 5 would be a good time for drop-in time, so I changed the schedule.
        After two more schedule adjustments, the thing seems to be working. I've learned that it's impossible to plan anything perfectly if it involves other people—you have to try it out, then be prepared to adjust a couple of times.

4. I keep my wallet in a different pocket. The first time I reached for my wallet, I was in an absolute panic—I was sure I lost it.
     My supporter pointed out to me that this may be the way people feel when I change things in the system and don't tell them—even if I do tell them, because they have the habit of finding things in certain places.

5. I made a healthier lunch for myself. I learned that I don't like "healthy" food. My supporter told me that I'm too healthy anyway, and the kind of lunch I made was rather fanatic. I guess she's right.
     It made me aware that I'm a perfectionist, but that it's not in the nature of human beings to be perfect. If I eat a pickle now and then, or a cookie, the world won't come to an end. Also, of course, if my teammates make a mistake in their code from time to time, or don't design something perfectly, we'll survive.

Meta-Challenge
   Here's a challenge about the challenge:
     When you accept this challenge, I'd love to read about what happened and what you learned. Hundreds of readers would like this, too. Besides, it will probably do you much good to sit down for a few minutes and recall your experience. Good writing practice, too.
     For more about Becoming a Change Artist, you can read the book and try the entire sequence of exercises.

Change Artist Challenge #1

2011-06-16T22:58:00.000-07:00

In an earlier post, I said that in order to be more effective introducing new techniques and technology, we needed to become practitioners of the art of change, as described in the seventh volume of my Quality Software ebooks: Becoming a Change Artist. In that book, I present a series of challenges taken from our change artistry workshops. In this and subsequent posts, I plan to present each of these challenges, roughly one every week. If you take each challenge, I guarantee you will substantially increase your change artistry.

Your first challenge will be to undertake a change project of your own, of a very specific nature. The purpose is to have you experience the Satir Change Model and some of its emotional consequences.

Challenge #1
Your challenge is to go to work tomorrow in a different way.

Experiences
The first experience of this assignment is what goes on in your head and heart when you first read it. Here are a few typical examples:

1. I immediately experienced panic (Chaos). What if I was late to work? I've already found the optimal way to work, because I've been driving it for four years. Suddenly, I understood exactly how it felt being in the Late Status Quo, and I knew that I would have more consideration for the people whose work I was trying to change.

2. My first thought was "impossible!" I simply could not think of a single alternative to the well-developed route I took to work. After all, there was only one bridge across the river. What was I supposed to do, swim? I decided I simply wasn't going to do it, which allowed me to relax. Then I realized that the assignment said 'in a different way,' not 'by a different route.' I hadn't even understood the foreign element, and I had rejected it.

Now consider some of the comments after doing the assignment:

3. I decided to go to work wearing a tie, which I've never done before. The reaction of other people was totally unexpected, both the number of people and their intensity. I learned how easy it is to be a foreign element, and that you can't change just one thing.

4. I went to work with a different attitude—more positive. The whole day was entirely different. It's a much better place to work than it was last week.

5. In driving by a different route, I got lost and discovered a part of the city I'd never seen before. I was late to work, but it was fun. I decided to go a different way each day, and I've been doing it now for six months. I like it.

6. I always go to work in a different way every day, so I wasn't going to do the assignment. Then I realized that a different way for me would be to go the same way. So I drove the same way every day for a week and learned a couple of things. First of all, the same way isn't the same way, if I pay attention. Second, I'm not the same every day. Some days I can't tolerate waiting for the light at 35th Street, but other days I welcome the time to reflect about things. I used this learning to reintroduce a proposal that had been rejected last month. This time they loved it.

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

Your next opportunity to participate in some change artist training is our Problem Solving Leadership Workshop (PSL). It takes place in Albuquerque, New Mexico, USA
August 28-September 2, 2011

After that, your next opportunity will be the 11th Annual Amplifying Your Effectiveness Conference (AYE) in Cary, North Carolina, USA
Sunday, October 30 – Thursday November 3, 2011
http://www.ayeconference.com

2011-06-09T20:24:00.001-07:00

If you're a writer, or hope to be, please read this article:

http://www.redhammer.info/news/agent-publisher/ http://amplify.com/u/a14tub

Beyond Agile Programming

2011-06-06T22:38:00.000-07:00

After being in the computing business now for more than half a century, one thing worries me more than almost anything else: our lack of a sense of history. In order to contribute my bit to addressing that problem, I've posted this essay—one that's sure to infuriate many of my readers, including some of my best friends. So first let me tell you how it came about.

While reformatting my book, Rethinking Systems Analysis and Design for e-booking, I noticed a few places that might have needed updating to present realities. The version I was using was more than 20 years old, from just after the peak of excitement about "structured programming." In particular, there was a whole section entitled, "Beyond Structured Programming." As I contemplated updating that section, it dawned on me that I could almost update completely by substituting the name of any more recent "movement" (or fad) for the word "structured.

I also knew how smart most of my readers are, so I figured they would see the same possibility without my updating a thing. Instead of changing the book, I decided to update the section and publish it on this blog. Why? Because I think it shows an important pattern—a script where only the names have changed over at least five decades. So, here is the section with "agile" substituted for "structured," just as "structured" had been substituted for some other fad a generation earlier.

The Restructured Essay
Before I proceed further with the task of rethinking systems analysis and design, I'd like to express myself on the subject of another great "rethinking" in programming—the agile programming revolution. Although this essay was written a generation ago (now two generation), and the agile programming "revolution" is now an exhausted fad (for most programmers), most of what this essay says still applies—though to the next rethinking fad, and the next, and the next. I believe it will still apply long after I'm no longer writing new editions. Why? Because our industry seems to require a new fad every decade to keep itself from being bored. So, just apply the lessons to whatever fad happens to be dominating the computer press at the time you're reading this.

Before anyone becomes overly enthusiastic about what the rest of this book says, I want to take stock of what this great agile rethinking has done. I don't claim to be starting a new revolution of the magnitude most of the fads claim, so I'd like people to realize how slow and how small the agile programming movement has been, in case they think this book is going to make much difference.

My own personal stock-taking on the subject of agile programming is based on visits to some forty installations on two continents over the past ten years, plus a few hundred formal and informal discussions with programmers, analysts, managers, and users during the same period. Because of the conditions under which these visits and interviews took place, I would estimate the sample is quite heavily biased toward the more progressive organizations. By "progressive," I mean those organizations more likely to:
• Send staff to courses
• Hire outside consultants, other than in panic mode
• Encourage staff to belong to professional organizations, and to attend their meetings.
Consequently, my stock-taking is likely to be rather optimistic about the scope and quality of the effects of agile programming.

The first conclusion I can draw from my data is this:
Much less has been done than the press would have you believe.
I interpret the word "press" very loosely, including such sources as:
• Enthusiastic upper management
• The trade press
• The vendors and their advertising agencies
• The universities, their public relations staffs, and their journals
• The consulting trade.
Although this may be the most controversial of my observations, it is the most easily verified. All you need do is ask for examples of agile programming—not anecdotes, but actual examples of agile behavior and agile-produced code. If you're given any examples at all, you can peruse them for evidence of following the "rules" of agile programming. Generally, you will find:

a. Five percent can he considered thoroughly agile.

b. Twenty percent can be considered to follow agile practices sufficiently to represent an improvement over the average code of 1990.

c. Fifty percent will show some evidence of some attempt to follow some "agile rules," but without understanding and with little, if any, success.

d. Twenty-five percent will show no evidence of influence by any ideas about programming (not just agile) from the past twenty years.

Please remember: these percentages apply to the code and behavior you will actually see in response to your request. If you ask software organizations at random for "agile examples," about two-thirds will manage to avoid giving you anything. We can merely speculate what they do, and what their code contains.

My second conclusion:
There are rather many conceptions of what agile programming ought to look like, all of which are reasonably equivalent if followed consistently.
The operative clause in this observation seems to be "if followed consistently." Some of these conceptions are marketed in books and/or training courses. Some are purely local to a single installation, or even to one team in an installation. Most are mixtures of some "patented" method and local adaptations.

My third observation:
Methods representing thoughtful adaptations of "patented" and "local" ideas on agile programming are far more likely to be followed consistently.
In other words, programmers seem disinclined to follow an agile methodology when it is either:
1. Blind following of "universal rules"
2. Blind devotion to the concept: anything "not invented here" must be worthless.

My fourth observation:
I have other observations to make, but now I must pause and relate the effect these observations have on many readers, perhaps including you. I recall a story about a little boy who was playing in the schoolyard rather late one evening. A teacher who had been working late noticed the boy and asked if he knew what time it was.
"I'm not sure," the boy said, "but I know it isn't six o'clock yet."
"And how do you know that?" the teacher asked.
"Because I'm supposed to be home at six, and I'm not home."
When I make my first three observations about agile programming, I have a similar reaction—something like this:
"These can't be right, because if they were right, why would there be so much attention to agile programming?"

In spite of its naive tone, the question deserves answering. The answer can serve as my fourth observation:

Agile programming has received so much attention for the following reasons:
• The need is very great for some help in programming.
• To people who don't understand programming at all, it seems chaotic, so the term "agile" sounds awfully promising.

• The approach actually works, when it is successfully applied, so there are many people willing to give testimonials, even though their percentages among all programmers may not be great.

• The computer business has always been driven by marketing forces, and marketing forces are paid to be optimistic, and not to distinguish between an idea and its practical realization.

In other words, the phrase "agile programming" is similar to the phrase"our latest computer," because each phrase can be used interchangeably in statements such as these:

• "If you are having problems in information processing, you can solve them by installing our latest computer."

• "Our latest computer is more cost effective and easier to use."

• "Your people will love our latest computer, although you won't need so many people once our latest computer has been installed."

• Conversion? No problem! With our latest computer, you'll start to realize savings in a few weeks, at most."

So actually, the whole agile programming pitch was pre-adapted for the ease of professionals, who have always believed "problems" had "solutions" which could be mechanically applied.

My final observation is related to all of the others:
Those installations and individuals who have successfully realized the promised benefits of agile programming tend to be the ones who don't buy the typical hardware or software pitch, but who listen to the pitch and extract what they decide they need for solving their problems. They do their own thinking, which includes using the thoughts of others, if they're applicable. By and large, they were the most successful problem solvers before agile programming, and are now even more successful.

There's yet another lesson in all this that's much bigger than agile programming or any new hardware or software or process:

Our profession contains few, if any, easy solutions. Success in problem solving comes to those who don't put much faith in the latest "magic," but who are willing to try ideas out for themselves, even when those ideas are presented in a carnival of public relations blather.
Based on this lesson, I'd like to propose a new "programming religion," a religion based on the following articles of faith:

• There's no consistent substitute for a thorough understanding of your problem, though sometimes people get lucky.

• There's no solution applicable to every problem, and what may be the best approach in one circumstance may be precisely the worst in another.

• There are many useful approaches applicable to more than one problem, so it pays to become familiar with what has worked before.

• The trick to problem solving is not just "know-how," but "know-when"—which lets you adapt the solution method to the problem, and not vice versa.

• No matter how much you know how or know when, some problems won't yield to present knowledge, and some aspects of the problem nobody currently understands, so humility is always in order.

I realize writing a book is not the most humble thing a person can do, but it's what I do best, and how I earn my living. I'd be embarrassed if anyone took this book too seriously. We don't need another "movement" just now, unless it is something analogous to a bowel movement—something to flush our system clean of waste material we've accumulated over the years.

Where to read the original
If you want to check on my historical work, you can find the original essay (and many others) in Rethinking Systems Analysis and Design, which is an ebook on Smashwords (where you can probably see it in the free sample) and Kindle and Barnes and Noble.

Problem-Solving Leadership Workshop
Reminder: The second (and last) PSL Workshop for 2011 will take place in Albuquerque, New Mexico, USA, August 28-September 2, 2011. Only a few places left for participants, so for more information, see <http://www.estherderby.com/workshops/problem-solving-leadership-psl http://www.estherderby.com/workshops/problem-solving-leadership-psl>

The Assumption of Fixed Requirements

2011-05-27T21:17:00.000-07:00

Note 1: This post is extracted from Chapter 9 of my book, CHANGE: Planned and Unplanned.

Note 2: This book was written for project leaders in high-tech industries, but writers are also project leaders, and writing certainly requires great skill and precision. For writers, requirements may originate from publishers, agents, and for-hire customers—any of whom can cause unending grief by changing those requirements for a writer who has assumed they were fixed.

Until recently, the computing industry seems to have avoided the subject of requirements the way a debutante might avoid the subject of indigestion. We knew such things existed, but if we didn't think about them, perhaps they would simply take care of themselves.
Many of the classic early papers in software engineering were based on the position:
This is how we would design and build software (if we had unchanging requirements.)

[For writers: each of us has her/his own process for writing, but for many of us, that process is also based on having unchanging requirements. If someone changes our task, we may be thrown off our game, and into write-stopping turmoil.]

For instance, many of the early papers on structured programming were based on the Eight Queens Problem, a problem of fixed definition with no input whatsoever. Many papers on recursive programming were based on the Towers of Hanoi problem, another problem of fixed definition with no input whatsoever. The more recent Cleanroom methodology has the same basis: "The starting point for Cleanroom development is a document that states the user requirements." The following quotation from Parnas and Clemens shows how deeply this assumption runs, even in the most sophisticated process designers.

Usually, a requirements document is produced before coding starts and is never used again. However, that has not been the case for [the software requirements for the A-7E Aircraft]. The currently operational version of the software, which satisfies the requirements document, is still undergoing revision. The organization that has to test the software uses our document extensively to choose the tests that they do. When new changes are needed, the requirements document is used in describing what must be changed and what cannot be changed. Here we see that a document produced at the start of the ideal process is still in use many years after the software went into service. The clear message is that if documentation is produced with care, it will be useful for a long time. Conversely, if it is going to be extensively used, it is worth doing right.

Parnas and Clemens describe the benefits of returning after design to create a requirements document as if it had been present from the beginning.

In the light of all this literature, it's easy to understand why so many software engineering managers have made the mistake of believing they should have unchanging requirements before starting any project. This model or belief is what I call the Assumption of Fixed Requirements, an assumption that is a misreading of these classical works. These classics were not addressing the entire process of software engineering, but only selected parts of that process. What they are teaching us is how to translate requirements into code, once we have reliable requirements.

Translating requirements into code is an essential part of software engineering, and it is the part that has received the most research attention over the past decades. Because of that attention, however, it is no longer the most difficult part of the process. Many organizations know how to do this part quite well, but the quality of their products does not adequately reflect their coding prowess.

In recent internal studies of serious quality problems, three different clients of mine arrived at quite similar conclusions. They divided the sources of the most serious problems into a number of categories, including coding and gathering requirements. In all cases, coding contributed least of all categories to quality problems, and my clients would perhaps do better to work on the less glamorous job of improving their logistics processes. Perhaps these rather advanced organizations are not typical of all software engineering organizations. They still have a lot to learn about coding and especially design, but in each case, the majority of their serious problems stem from requirements.

Software engineers and their customers perceive quality differently, and this table accounts in large part for that discrepancy in perception. Over the past decades, engineers have seen coding faults drop dramatically as a result of their quality improvement efforts. The customers, however, have not seen a comparable decrease in the number of requirements problems, and so do not perceive the same increase in quality as the engineers, who are paying attention to their own priorities—which don't happen to coincide with their customers' priorities. The engineers need to learn that they will never become an Anticipating organization by getting better and better at coding—even though that was the improvement process that brought them as far as they've come.

Writers Are Losing the Fight Again

2011-05-11T21:30:00.000-07:00

Dean Wesley Smith has written another scathing post about "agents" trying to scam writers in "the new world of publishing." Please read it: http://www.deanwesleysmith.com/?p=4096&cpage=2#comment-9194

It's a terrific post, which it has in common with all Dean's posts, but this time he made one little mistake, so I had to write a comment on his blog.

But there are so many comments (as there should be, and you should read them all), you might miss mine, so I'm repeating it here.

Dean,

I’ve been thinking about this whole scheme and decided it’s not a scam at all. It’s actually a terrific idea, with only one slight flaw.

All that it needs to make it a fair deal is to make it symmetrical. In particular, the agents have the right idea about expenses. This is a business, and it’s quite right that the partners in such a deal should be reimbursed for their expenses before any royalties are distributed.

So, I’m looking for an agent who will write a contract with me where s/he gets expenses and so do I. Let’s see, what are my expenses?

Well, there’s toner for my printer.

And several reams of paper.

And the printer itself.

And the computer.

And the software.

And my office, and its furnishings.

Let’s see. What have I forgotten. Oh yes, there’s about 20 years of schooling so I could learn how to write. Let’s figure conservatively about $50,000 per year. It’s probably a lot more, but we don’t want to take advantage of the poor agent, so we just have $50,000 times 20, which seems to come to $1,000,000 before I could write a word.

Now of course, my schooling was a long time ago, so if I hadn’t spent that money learning how to write, I could have put it into US Treasury bonds and easily earned, say, 6% on the average. And I finished my schooling roughly 50 years ago, which means the $1,000,000 would have doubled roughly 4 times since then, making $16,000,000 today.

Don’t you just love this calculating “expenses”? (That's an important part of the new agent scam contract.)

The way I figure is I’d happily sign with an agent who’d give me $16,000,000 up front to cover my expenses.

Or, since I’ve published roughly 100 books, I’d be willing to take $160,000 up front from any agent wanting to contract with me to handle a book of mine.

So, agents, if you’re reading this, better hurry and get your cash in hand and contact me before all those other agents beat you to the punch.

Yes, Dean, I’m sorry, but you’re just going to have to write a retraction saying what a good deal these new agent ideas are for writers. Agents, please insist on it.

Oh, and by the way, here are two of my most recent eBooks, which you can sample at http://www.smashwords.com/profile/view/JerryWeinberg?ref=JerryWeinberg and purchase them there, or at Amazon or Barnes and Noble.

Project Mercury

2011-05-05T11:15:00.000-07:00

I was one of the workers on Project Mercury. My job was to design and implement the space tracking network, and particularly the multiprogrammed operating system that ran the entire network. Many readers have asked me about Mercury, so here's a little something courtesy of SPACE.com:

Source SPACE.com: All about our solar system, outer space and exploration

"Smashwords vs. Kindle?" Are Your Lights On?

2011-04-17T22:05:00.000-07:00

Yesterday, Don Gause and I posted out book on problem definition, Are Your Lights On?—a book many have called a "classic."

Today, I ran across a perfect example of why the lessons in the book are so useful. On one of the writers' forums in which I participate, a reader posted a query entitled Smashwords vs. Kindle? Here it is:

Gemma, a writer, asks:

Can someone tell me what the benefits or advantages of publishing on Smashwords might be when Amazon, the number five most visited site in the USA, (according to Alexa.com) provides such a successful solution and so much higher traffic? To compare, Smashwords ranks 2,751 in terms of daily traffic. Amazon's "query popularity" is 86 out of 100, versus only 38 out of 100 for Smashwords. Amazon visitors spend an average of eight minutes on the site and view 8.8 pages while Smashwords visitors spend six minutes on the site and view 6 pages.

Still, I have found the folks on this list to be a savvy bunch, so I suspect there must be some hidden advantages or benefits of which I am unaware. Can anyone who has published on Smashwords help me out by sharing some benefits? I am about ready to put up some titles on Amazon and had decided to stick exclusively to that platform and to B & N, but maybe I am cutting off potential sales by not posting on Smashwords.

Perhaps someone else has the answer already:

One of the things Are Your Lights On? teaches is to use all the information you have. In this case, I had an earlier answer from another author, "Linda."

Linda offered this answer:

Yes, Amazon offers worldwide traffic, but Smashwords offers retail eBook outlets that we do not get at Amazon. My books are directly at Amazon Kindle. And then I have also added a number of my books and my husband's at Smashwords to take advantage of the retail outlets they distribute to. At Smashwords I opt out of Amazon, and will continue to do so. But Smashwords has not only their direct website, but the books are sent to the ebook retailers-- Kobo, Nook, Diesel, IPad, etc. I love being able to check daily on my Kindle sales and be paid monthly by Kindle. Royalty payments and sales via the Smashword's distributors are slower, depending on the retailer.

So the advantage is having more retail distribution (and hopefully sales) by putting your books at Smashwords, in addition to having them at Amazon Kindle.

Even good answers may not be complete.

Are Your Lights On? teaches:

"If you can't think of at least three things that might be wrong with your understanding of the problem, you don't understand the problem."

Well, I really liked Linda's answer, but applying the Rule of Three, thought about how it could be improved.

Jerry adds to Linda's answer:

First of all, listen to Linda. She and her husband use exactly the same strategy Dani and I use. [Note from AYLO: Answers don't just have to be right, they have to be convincing. Supporting Linda's excellent answer is the first job a consultant has to do to be effective in this case.]

So, my first answer to Gemma is this: You've done your research, and done it well, but the data you've gotten happens to be irrelevant to this problem. The traffic each site receives doesn't really matter. What matters is selling books. Suppose Site A receives 1000 hits/day, and the average stay is 10 clicks, and they sell one book per day. Site B receives 10 hits per day, and the average stay is 1 click, and they sell two books per day. Which is better for you, the writer, A or B?
The answer is "none of the above." Why, because you don't have to choose. You can put your book on both A and B's sites, and sell three books.

On to the details:

Once you have the right problem definition, the solution is often trivial, as above. Since I can't verify my assumptions about Gemma's problem definition, I can add some other facts to support various definitions, such as,

1. A book sold at Smashwords gets a higher royalty than the same book sold at Kindle. For each $7 of Kindle royalty, the same sales on Smashwords earn $8.

2. Smashwords, as Linda says, distributes to many retail outlets that would be a pain to reach individually, and perhaps not worth the small sales they generate. Through SW, I reach them with zero extra effort.

3. In addition to extra retailers, I reach readers who don't use Kindle. As Linda says, SW formats automatically for just about every eReader known to humanity, again, at zero extra effort.

4. I don't know how many SW sales I would have through Amazon if SW weren't available, but I do know that through SW, I earn about 2/3 of what I earn through Kindle, so instead of, say, $1,000 through Kindle, I earn about $1,666 through the combined offering. (plus another $100 or so through Barnes and Noble, which you should also use.)

5. SW has a "coupon" feature that Amazon doesn't offer. That allows me to offer special price deals for a day, a week, a month, or whatever period of time I wish, for whatever price I wish. Very useful for marketing, and for reviewers. On Kindle/Amazon, a price change takes about three days to start, and three days to remove, and is seen by the whole world. On SW, the change takes place instantly, and can be removed instantly. I can offer it to one person, or 10, or 100, or to the entire internet world. My choice.

6. And, if you offer a book on SW, you can pull the book(s) any time you want. So, if it turns out you don't like something about SW, you're out of the deal instantly, whenever you want--not cost, no fuss. It's totally under your control.

Bottom Line

Yes, the book-selling business can be complicated, but this one's probably a no-brainer when you have all the facts—if I have the right problem definition. In a real consulting situation, I'd be able to talk with Gemma and verify that I understand her problem. Since I don't have access to her, I'm guessing that her implicit problem definition is wrong from the start.

Gemma, I think it's not "Smashwords vs. Kindle," but "Smashwords and Kindle" (and Barnes and Noble, and any other sites you wish, as long as they don't restrict your publishing elsewhere).

Perhaps the definition would have been better stated: "How can I achieve the best sales results for my eBook?"

P.S.

You can sample Jerry's books on Smashwords, including Are Your Lights On?, then buy them there or at any other site you might prefer. See and sample all my books on Smashwords (more going up all the time).

It Flies! Da Vinci's Dream Comes True

2011-04-12T22:12:00.001-07:00

URL: http://www.npr.org/blogs/krulwich/2011/04/11/135300971/...

by Robert Krulwich

This is not a trick. There are no invisible strings, no post production video fixes. What we have here is a graceful, flapping, unfeathery machine that looks and flies like a seagull. It was built by a team of engineers at a company called Festo in Germany, which specializes in factory automation, and for years now they've been doing what Leonardo dreamed of when he sat on those hills near Florence sketching birds: they copy from nature's designs.

Watch the movie! See the artificial bird fly! - Jerry

See this Amp at http://amplify.com/u/bywp6

How Fast is Fast Writing?

2011-04-11T23:03:00.000-07:00

See my guest post on Ellis Vidler's blog: "How Fast is Fast Writing?" http://ow.ly/4ycjq

Learned Helplessness

2011-04-03T20:54:00.000-07:00

My e-pal, L.M. May has written the most striking, useful blog post I've seen in a long time. L.M. says: "The following essay is about fiction writing and learned helplessness, ..." but L.M. "used to work in the software industry as a software tester," and so writes this essay with much the same qualifications I have—and combines the two main foci of this blog: writing and software creation. So, if you're a writer, or a software professional (or both), this essay is for you.

What is "learned helplessness," and what does it have to do with writing and software making? I'll leave the writing part to L.M., but I'd like to cover the software side briefly, before I send you off to read the essay, at:

http://lmmay.com/2011/04/03/fiction-writers-and-learned-helplessness/

L.M. quotes the Wikipedia definition, "Learned helplessness…means a condition of a human being or an animal in which it has learned to behave helplessly, even when the opportunity is restored for it to help itself by avoiding an unpleasant or harmful circumstance to which it has been subjected."

The essay was inspired by the reactions of some writers to the enormous technology-induced changes taking place in the publishing industry. (See, for example, my posts of Feb 27 and Feb 28, on this blog.) These writers had learned that the only real way to publish their books was the traditional way, as books printed on paper by a few large publishing companies. Mostly, they had put their entire business of writing in the hands of agents who dealt with these companies for them. Now, with e-publishing, they have an avenue for bypassing all those "helpers" (and their fat fees), but some of them, many of them, have learned to be helpless, and violently oppose the idea of standing on their own two feet as adults.

How does this relate to software professionals? If you really don't understand, I'm not sure I can explain it to you. To put it briefly and bluntly, have you ever allowed the "grown-ups" (the salespeople, the managers, the customers) to override your professional judgment because you felt helpless?

Did you ever agree to build some code in two months when you knew it would take at least five—and then silently take the blame when you made it in four?

Did you ever allow unqualified people to override your technical decisions, thinking you couldn't do anything about it?

Have you agreed to undertake testing software that was (to you) obviously unready for testing (or even patently untestable)?

Even if you've never experienced such events, have you ever watched others trapped by them, and not known how to help them?

If you know about such matters in your work, read L.M.'s essay about the psychology of learned helplessness, then come back here and be a voice in the conversation that follows.

And why here? LM explains:
"I keep my comments section off due to family and work commitments, but Dean Wesley Smith and Gerald M. Weinberg offered their blogs as sites where people could discuss this essay amongst themselves. I will be checking in as often as I can to both their websites over the next few days to answer any questions."

I think we should divide the labor, with the writers' comments going to Dean's site (http://www.deanwesleysmith.com/) and the software people laying out their thoughts here. But you can choose where to hang out—both places, if you wish—and we'll see what comes of our sharing.

And, BTW, as you dig into this subject, you may want to try my ebook, Managing Yourself and Others, or at Amazon or Barnes & Noble.

Managing Yourself

2011-03-31T16:10:00.001-07:00

This is why I wrote the book, "Managing Yourself and Others."

<https://www.smashwords.com/books/view/39685?ref=JerryWeinberg>

Mostly, it's about congruence!

Amplify’d from techcrunch.com

What’s The Most Difficult CEO Skill? Managing Your Own Psychology.

By far the most difficult skill for me to learn as CEO was the ability to manage my own psychology. Organizational design, process design, metrics, hiring and firing were all relatively straightforward skills to master compared to keeping my mind in check. Over the years, I’ve spoken to hundreds of CEOs all with the same experience. Nonetheless, very few people talk about it, and I have never read anything on the topic. It’s like the fight club of management: The first rule of the CEO psychological meltdown is don’t talk about the psychological meltdown.

At risk of violating the sacred rule, I will attempt to describe the condition and prescribe some techniques that helped me. In the end, this is the most personal and important battle that any CEO will face.
Read more at techcrunch.com

See this Amp at http://amplify.com/u/bxclo

Knowing What to Leave Alone

2011-03-29T21:06:00.000-07:00

I adapted this blog post from my new eBook, Becoming a Change Artist This little case example followed a number of other examples, as a kind of corrective to some peoples' ideas about how a change artist operates.

I don't want to give the impression that change artists are rushing around an organization inflicting help on everyone. Perhaps the toughest skill for a change artist to learn is the skill of knowing what people and what situations to leave alone.

For instance, there's a Vietnamese proverb that says, "While it is notable to assist a stricken elephant in rising, it is foolhardy to catch one that is falling down." Change artists need to learn how to recognize whether a person or department is willing to help themselves rise.
For instance, change artists should have lots of potentially transforming ideas on hand. Most of these ideas are on the process level—that is, processes for finding ideas. Such processes might include

reaching out to other organizations, departments, professional societies, libraries, consultants, or classes
facilitating brainstorming processes
keeping an inventory of sample problems, toy exercises, and simulations for right-brain exploration and left-brain investigations
conducting focus groups, and knowing how to recognize when the group lacks the necessary knowledge (A lens doesn't focus anything if there's no ray of light.)
changing the mixture of people to obtain more diversity and knowledge
combining ideas from several sources to produce new ideas

A good example of combining of ideas is the process of connecting what the individuals want with what the organization or the change artist wants. If the change artist thinks the elephant might be falling down, she might make her presence (what they want) conditional on their participation (what she wants). Or if management wants the group to take a risk, the change artist might negotiate some kind of insurance to give the group safety, such as extra time in the schedule, relaxed specifications, suspension of the usual measurements, or a guarantee of their old jobs back if the project flops.

Here's an example of this kind of negotiation. In an organization producing electronic equipment with embedded software, top management threw in a foreign element by mandating certain process improvements. Some of the more traditional managers were highly technical engineers, and claimed that the other managers, being service engineers, weren't sufficiently technical to do process improvement. Thelma, a change artist, was supposed to facilitate the entire group of managers working on the improvements, but she faced a problem: Who should have the job, given that the technical managers weren't doing it, and the service managers wanted to do it?

Thelma applied several change artist principles:

Always find the energy for change and go with it. In this case, the service managers wanted to work on change, and the technical managers didn't.
Don't get hooked into negative energy. The technical managers knew dozens of reasons why these changes could not be made.
Talk in their terms and find out what the issues really are. It turned out that the technical managers were overloaded with assignments just getting products out the door. The service managers were overloaded, too, but they felt that their overload was due to service requests arising from faulty technical processes. They were willing to invest their time to reduce their future load.
Once you're prepared, go to the source. Having assembled all these facts, Thelma made a recommendation to upper management that the service managers be given the process improvement responsibility, and that the technical managers no longer be required to attend process improvement meetings. In return, the technical managers promised their full cooperation on an as-needed basis. Upper management was happy to accept her solidly-based recommendation.
It's perfectly all right to do nothing for a time. Dormancy periods in seeds and hibernation in animals are adaptive strategies in an environment with fluctuating opportunities for growth. In human organizations, the Zone Theory says that it sometimes makes good sense just to lie low during periods of rapid change. Knowing that Chaos is contagious, Thelma wisely decided to leave the technical managers alone. Their time would come.

In other words, just like in artistry with a canvas, paint, and a brush, sometimes the empty spaces are the most important part of the work of art.

To perfect your change artistry, you might want to participate in this year's AYE Conference.

Are you a permission giver? Feynman was.

2011-03-27T16:06:00.001-07:00

Read the entire article, then read Feynman's letters.

Amplify’d from www.theamericanscholar.org

Permission Givers

By William Zinsser

When Richard P. Feynman, one of the giants of 20th-century physics, was awarded the Nobel Prize in 1965, he received hundreds of congratulatory letters from friends and admirers, including one from a former student named Koichi Mano. Acknowledging the letter, Feynman asked the young scientist what he working on. Koichi sent a doleful reply, regretting that he wasn’t working on fundamental problems of science, but only on “a humble and down-to-earth type of problem.”

“Your letter made me unhappy,” Feynman wrote back, “for you seem to be truly sad. No problem is too small or too trivial if we can really do something about it. It seemed that the influence of your teacher has been to give you a false idea of what are worthwhile problems.” In his own career, Feynman pointed out, he had “worked on innumerable problems that you would call humble, but which I enjoyed and felt very good about because I sometimes could partially succeed.” He went on to describe a dozen of those experiments, some of which failed, including one on the theory of turbulence that he “spent several years on without success.”
Read more at www.theamericanscholar.org

See this Amp at http://amplify.com/u/bwosl

How to Manage Teams Congruently

2011-03-20T10:07:00.000-07:00

Typical crisis-provoking events in the life of a programming team are machine malperformance, machine overload, unyielding bugs in critical sections, difficulties in system testing of two unit-tested programs, schedule changes, arrival of new equipment, changes in higher-level management, and changes in specifications. No wonder it seems that crisis is the normal situation in the life of a programming team.

Two general social-psychological observations about group behavior are especially relevant to the crisis-ridden programming team. First of all, it has been observed that in a crisis, members of a group more readily accept relatively strong leadership attempts. At the same time, however, the group becomes less patient with would-be leaders if their direction does not produce effective solutions to group problems rather quickly. Thus, in a programming team—which is possibly in a continual crisis—leadership patterns may be in constant flux. Because of this reshuffling, the more difficult the task is, the more the team comes to follow those leaders who can actually steer the team most effectively.

We can see, then, why the democratic—or perhaps we should say "technocratic"—organization is such a natural one for a programming team. When selecting programmers for teams, we should try to choose people who will fit well within such a self-shifting structure—neither too dominant nor too passive. In training our programmers, we should try to teach them how to follow able leaders and how to grasp leadership opportunities when they themselves are the most qualified in the group. And during the life of a team, we should try—if we are on the outside—not to interfere in those democratic processes which, though seemingly traumatic for the team and its members, will in the long run lead to most effective team functioning.

Indeed, once the team is selected and operating, the wise manager placed above it will adopt a "hands-off" policy with regard to its internal structure and structure change. When, as so often happens, team members come to him to lend an authoritative opinion on their side of some argument, he would do well to follow the pattern of the old rabbi who was sitting in his study one day when an obviously agitated man came to see him. The man told him a long story about an argument just concluded with his wife. When he finished his story, he insisted that the rabbi tell him whether he or his wife had been right.

"You're right," said the rabbi, and the man left the house beaming. Soon, however, the man's wife appeared—even more distraught than the man had been.

"What do you mean," she insisted, "saying that my husband was right? You haven't heard my side of the story." And she proceeded to relate her side, finishing with a demand for a new judgment.

"You're right," said the rabbi, and the wife left satisfied. The rabbi's own wife, however, was not satisfied, for she had overheard both stories and both answers.

"How can you do that?" she demanded. "You told the husband that he was right and the wife that she was right. They can't both be right."

"You're right," said the rabbi.

[This little tale is adapted from my books: The Psychology of Computer Programming and Managing Teams Congruently.]

A fine article, but only a sample

2011-03-04T22:50:00.001-08:00

I chose just one of the many fine entries on the TESTHEAD blog. Read this one, then try some of the others. Michael can write--but most of all, he can think!

Amplify’d from mkl-testhead.blogspot.com

Army of One: Pairing With an Expert

One of the challenges being a lone gun tester is the fact that, often, you don’t have someone else to ask questions with. Sure you can talk to developers about issues and areas you have concerns about, but that’s not what I mean. It’s rare that time will allow a person to consistently sit down with a developer and just ask broad and open-ended questions about a product, a technique or an idea. Larger test organizations allow testers to have this opportunity. Frequently, the Army of One tester ends up doing most of their thinking or brainstorming alone… but they don’t have to.

Today I had a cool experience. One of our domain knowledge experts had some time today and asked if we could set up a pair testing session, with the idea of “asking the product some questions”. The domain expert in this case is an Attorney very well versed in Immigration Law. There are a lot of layers to testing software that services the legal profession, which my company does. While I know a fair amount about Immigration and Employment Law just by virtue of repeatedly testing and looking at the challenges our products are meant to address, I will not have the same level of experience or expertise that a dedicated attorney would have.

Read more at mkl-testhead.blogspot.com

See this Amp at http://amplify.com/u/bsxk5

It's the publishing wave of the future

2011-02-28T20:38:00.001-08:00

Pay attention to Mr. Lankford!

Amplify’d from www.publishersweekly.com

Waiting for a Fair E-book Split - David to Goliath: Keep the Advance

By Terrill Lee Lankford

things

During a recent conversation about the new book, the editor once again mentioned that he also wanted to release an e-book version of my first novel, Shooters. I reminded him that I didn't want to do that until we were solidly in business together on the new work. After the call, I started thinking about the e-book aspect of the deal again, which we hadn't discussed in many months. At that time he had said e-book rights would be "highly negotiable." But I knew things had been changing rapidly on that front so I sent him an e-mail asking, "What is the current split for e-books?" His response: "The split for e-books is 75% publisher, 25% author." Me: "Do you have that backwards?" E-silence. I sent another note: "I'm serious: was this a typo? Does the publisher actually take 75%?" Him: "Yes. The publisher takes 75%." Me: "This amazes me. No amount of ‘platforming' can justify this. If that's the rate they expect me to accept, I'm going to have to pass. On both projects."
Read more at www.publishersweekly.com

See this Amp at http://amplify.com/u/bs3ju

Who Can Alienate Readers Better?

2011-02-27T12:04:00.000-08:00

I'm an author who's old enough to remember when the people who ran "Big Publishing" were book people—people who had some fairly decent intuition about books and the people who read them (in other words, their products and their customers). My first book was published by McGraw-Hill They were the biggest of the big, but they treated me with respect. For example, when I spotted trouble on my royalty statement, the situation was handled personally by the company president (one of the McGraws).

Four McGraw-Hill books later, the company was having some trouble over a bogus Howard Hughes biography, and turned down every new project for a year—including my latest manuscript, The Psychology of Computer Programming. I was naive enough to be shocked that a publisher might turn down a good book, so thought I must have done something wrong. After moping for a year of self-doubt, I recovered sufficiently to circulate the book to four publishers and was offered a contract by each of them. I chose Van Nostrand.

A year later, when the printed book was delivered, I went down to NYC to receive my first copy from the hand of my editor (a ritual I had practiced with McGraw-Hill). When I suggested we go to my editor's office to sit down and talk, he told me he didn't have an office—because he had just been fired.

Turns out he'd been fired by the corporate executives for publishing my book. In the interval since contract signing, Van Nostrand had been purchased by Litton Industries, along with (as I recall) four other publishers. The idea was to convert publishing to a "proper" business model—and this was the first such acquisition/consolidation, the one that began this new era in the publishing industry.

This new model included taking editorial responsibility out of the hands of the editors (real book people) and putting it into the hands of the executives (real business people).

Apparently their business intuition told them the book wouldn't sell, but apparently that intuition didn't work. In spite of fantastic order fulfillment screw-ups (another byproduct of the acquisition/consolidation, but that's another story), The Psychology of Computer Programming outsold all other similar books in Van Nostrand's inventory. It's still selling (I got the rights back—another stupid business decision by the executives—and the book is still selling steadily after almost 40 years—over 250,000 copies in a dozen languages. (It will be out soon as an eBook.)

And, after 40 years, these business executive are still clueless about that "book business," as opposed to their "book business." If you don't believe that, watch them screwing up the eBook business in just about every imaginable way. (Nobody said they weren't creative.) For instance, here’s what MacMillan CEO John Sargent recently had to say about libraries and ebooks:

"That is a very thorny problem”, said Sargent. In the past, getting a book from libraries has had a tremendous amount of friction. You have to go to the library, maybe the book has been checked out and you have to come back another time. If it’s a popular book, maybe it gets lent ten times, there’s a lot of wear and tear, and the library will then put in a reorder. With ebooks, you sit on your couch in your living room and go to the library website, see if the library has it, maybe you check libraries in three other states. You get the book, read it, return it and get another, all without paying a thing. “It’s like Netflix, but you don’t pay for it. How is that a good model for us?"

"If there’s a model where the publisher gets a piece of the action every time the book is borrowed, that’s an interesting model." - from http://go-to-hellman.blogspot.com/2010/03/ebooks-in-libraries-thorny-problem-says.html

If you don't understand what's wrong with this statement, take a look at the article and comments, "Friday Alert: HarperCollins in cagematch with Macmillan to see who can alienate readers better." <http://dearauthor.com/wordpress/2011/02/25/friday-alert-harpercollins-in-cagematch-with-macmillan-to-see-who-can-alienate-readers-better/>

Or, if that's not helping, take a look at past history—for example, the reaction of the Western Union executives when the technology for voice-over-wire (telephone) became available. Or, study the music industry executives' bungling of the digital music scene.
Whichever example you choose, it's always the same pattern of response to new science or new technology: The people on top of the existing industry always try to stifle the new in order to preserve the old. They bungle, and that opens the door for all sorts of brash newcomers. Brash, that is, until they become the fat cats and play the same bungling role when the next innovation comes along—as it always does.

The only question is "Who will be the brash newcomers this time around?"

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Find my eBook novels and nonfiction listed at these stores

• Barnes and Noble bookstore: http://tinyurl.com/4eudqk5

• Amazon Store: http://amazon.com/-/e/B000AP8TZ8

• Apple Store: http://apple.com

• Smashwords Store:
http://www.smashwords.com/profile/view/JerryWeinberg?ref=JerryWeinberg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Ins and Outs of Planning a Conference Program

2011-02-21T22:34:00.000-08:00

In response to a number of reader requests, I've asked author Marilyn Meredith to give us an essay on her experience with conference planning. She graciously consented, so here it is:

Public Safety Writers Associations’ Annual Conference

Planning the program for the Public Safety Writers Associations' annual conference is probably different in some ways for planning for other writers' conferences.

The membership is made up of active and retired law enforcement officers and firefighters, people who write articles for law enforcement and other public safety publications, non-fiction writers, and mystery writers—although there are no requirements about who can attend the conference.

When I first started with the job I had to dig a little deeper to find speakers and mainly those who came concentrated on writing topics. This year we are having some speakers who will be talking about writing topics including voice, characterization, writing thrillers, and screen writing, but we also have a police psychiatrist and a county coroner.

Some speakers have been attendees of the conference who have come to me at the conference suggesting a topic they would like to present. Others have contacted me after the conference offering their services. All of our speakers must pay for the conference just like everyone else—and there is no other compensation.

We also have panels which are usually writing topics like editing, about creating setting, writing for trade publication and promotion. This year we'll have one on writing with a partner, and a panel of experts (forensic expert, military person, lawyer, FBI agent) telling us what TV gets wrong.

It's up to me to figure out the schedule and I like to stagger the speakers in-between the panels.

We are always on a tight time-schedule; 15 minute breaks between the 45 minute presentations, so volunteers serve as time keepers, displaying signs to notify how much time is left. Some attendees love this job.

And as for the problems that occur sometimes: Once in awhile I have to switch the program around a bit because someone couldn't make it to their slot on time, or got sick, or just didn't show up. One plus to having so many professionals gathered together, there's always someone interesting who can fill in.

For anyone interested in finding out more about this conference, go to http://www.policewriter.com

Anyone wanting to be on a panel must register before June 1 so I can finalize the program, however someone can come to the conference and pay on the day it begins.

I love this conference because of all the interesting people I've met and become friends with and are invaluable for research. Because I write about a sheriff's deputy in one series and a whole police department in another, these people have become invaluable to me.

F.M. Meredith, also known as Marilyn Meredith, is the author of nearly thirty published novels. Her latest in the Rocky Bluff P.D. crime series, from Oak Tree Press, is Angel Lost. Marilyn is a member of EPIC, Four chapters of Sisters in Crime, including the Internet chapter, Mystery Writers of America, and on the board of the Public Safety Writers of America. Visit her at http://fictionforyou.com and her blog at http://marilynmeredith.blogspot.com

Angel Lost, an E. F. Meredith Crime Novel

As plans for her perfect wedding fill her mind, Officer Stacey Wilbur is sent out to trap a flasher, the new hire realizes Rocky Bluff P.D. is not the answer to his problems, Abel Navarro's can't concentrate on the job because of worry about his mother, Officer Gordon Butler has his usual upsets, the sudden appearance of an angel in the window of a furniture store captures everyone's imagination and causes problems for RBPD, and then the worst possible happens—will Stacey and Doug's wedding take place?

Authors You May Not Know–Yet

2011-02-20T11:33:00.000-08:00

The writing business is one of the most difficult to break into. (into which to break?) Excellent writing and story-telling are not sufficient to publicize your name and what you can do. I do my primary publicizing through my website:

http://www.geraldmweinberg.com

and through various book retailers such as Amazon, Barnes and Noble, and Smashwords.

I also belong to a number of groups of aspiring writers, including one called Backlist Books. One of the ways we spread the word about ourselves is to exchange links to our blogs and/or websites. Below, I've placed a list of some of the backlist authors I like. There's a wide variety of genres, so take a look at them and see if there's anything to your taste. You'll be glad you did.

Doranna Durgin, http://doranna.net/wordplay

Marsha Canham, http://marshacanham.wordpress.com

Jacqueline Lichtenberg, http://aliendjinnromances.blogspot.com

Jeffrey A. Carver, http://starrigger.blogspot.com/

Jill Metcalf, http://jillmetcalf.wordpress.com

Terry Odell, http://terryodell.blogspot.com

Maryann Miller, http://its-not-all-gravy.blogspot.com/

Patricia Rice, http://patriciarice.blogspot.com

Pati Nagle, http://patinagle.livejournal.com/

Lorraine Bartlett or Lorna Barrett, http://www.LornaBarrett.blogspot.com

Karen Ranney, http://karenranney.wordpress.com

No More Reviews—With Exceptions

2011-02-11T10:32:00.000-08:00

My call for reviewers has been so successful, I'm flooded with requests for free books.

For the moment, I'd like to suspend the reviewing (until next time) with the exception of readers who are willing to review some of my novels—which are under-reviewed.

So, if you want to review one of my novels, let me know. If you're interested in one of the non-fiction, you'll have to buy it (the e-book versions are very inexpensive) or wait until the next free book offer.

For the novels, you can see them and sample them at

http://www.smashwords.com/profile/view/JerryWeinberg?ref=JerryWeinberg

And thanks to everyone who has responded.

Free books! Looking for a Few More Book Reviewers

2011-02-10T14:26:00.000-08:00

This post is about marketing. As you probably know, I'm in the business of writing books, as part of my consulting business (or vice versa). In the modern publishing world, with more and more books bought online, customer reviews really can help books reach their full potential. Although we work with professional reviewers as well, you don’t need to be a professional reviewer to review books for me. Any avid reader can do it!

Right now, I'm looking for a few more people to help spread the word about my books. If you’re interested, please email me at hardpretzel (at) earthlink.net with the words “Book Reviewer” in the subject line.

I’ll email you back with a password that will give you access to one of my titles in Kindle, PDF, and ePub format, for your computer or your reading device.

Here’s my current titles, with more on the way:

http://www.geraldmweinberg.com

All I ask is that you review whatever book you download on either Amazon or Smashwords or Barnes and Noble’s website (or all three—that’s even better). If you’re a professional reviewer, it’s great if you review it on your blog or website, and I’ll often link to it from my own site, but I still ask that you post your review to at least one of the three just mentioned.

It’s easy to do, and you don’t even need to use your real name if you like. Five or six sentences is fine, though you can certainly write more if you wish. Have fun! And if you’re not sure how to do it, just read some examples.

Please note: It would be unethical to require you to do a positive review; all I ask is that you’re fair, and that if it’s just not your kind of book (remember, everyone has different tastes), that you just pass on doing the review at all. In the modern book selling world, these reviews have become critically important to helping books reach their full potential. Keep this in mind when you’re reviewing and you’ll be just fine: I’ve staked many hours on my novels and nonfiction.

I can give away only so many free books, so I’ve limited this round of book reviewers. If interested, please email us ASAP.*

(Thanks for this idea to Scott at Flying Raven Press, http://flyingravenpress.com/. Why not give them a visit.)

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

2011-01-28T22:03:00.000-08:00

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 Universal Pattern of Huge Software Losses

2011-01-04T11:33:00.000-08:00

What Do Failures Cost?
Some perfectionists in software engineering are overly preoccupied with failure, and most others don't rationally analyze the value they place on failure-free operation. Nonetheless, when we do measure the cost of failure carefully, we generally find that great value can be added by producing more reliable software. In Responding to Significant Software Events, I give five examples that should convince you.

The national bank of Country X issued loans to all the banks in the country. A tiny error in the interest rate calculation added up to more than a billion dollars that the national bank could never recover.

A utility company was changing its billing algorithm to accommodate rate changes (a utility company euphemism for "rate increases"). All this involved was updating a few numerical constants in the existing billing program. A slight error in one constant was multiplied by millions of customers, adding up to X dollars that the utility could never recover. The reason I say "X dollars" is that I've heard this story from four different clients, with different values of X. Estimated losses ranged from a low of $42 million to a high of $1.1 billion. Given that this happened four times to my clients, and given how few public utilities are clients of mine, I'm sure it's actually happened many more times.

I know of the next case through the public press, so I can tell you that it's about the New York State Lottery. The New York State legislature authorized a special lottery to raise extra money for some worthy purpose. As this special lottery was a variant of the regular lottery, the program to print the lottery tickets had to be modified. Fortunately, all this involved was changing one digit in the existing program. A tiny error caused duplicate tickets to be printed, and public confidence in the lottery plunged with a total loss of revenue estimated between $44 million and $55 million.

I know the next story from the outside, as a customer of a large brokerage firm:
One month, a spurious line of $100,000.00 was printed on the summary portion of 1,500,000 accounts, and nobody knew why it was there. The total cost of this failure was at least $2,000,000, and the failure resulted from one of the simplest known errors in COBOL coding: failing to clear a blank line in a printing area.

I know this story, too, from the outside, as a customer of a mail-order company, and also from the inside, as their consultant. One month, a new service phone number for customer inquiries was printed on each bill. Unfortunately, the phone number had one digit incorrect, producing the number of a local doctor instead of the mail-order company. The doctor's phone was continuously busy for a week until he could get it disconnected. Many patients suffered, though I don't know if anyone died as a result of not being able to reach the doctor. The total cost of this failure would have been hard to calculate except for the fact that the doctor sued the mail-order company and won a large settlement.

The Pattern of Large Failures
Every such case that I have investigated follows a universal pattern:

1. There is an existing system in operation, and it is considered reliable and crucial to the operation.

2. A quick change to the system is desired, usually from very high in the organization.

3. The change is labeled "trivial."

4. Nobody notices that statement 3 is a statement about the difficulty of making the change, not the consequences of making it, or of making it wrong.

5. The change is made without any of the usual software engineering safeguards, however minimal, that the organization has in place.

6. The change is put directly into the normal operations.

7. The individual effect of the change is small, so that nobody notices immediately.

8. This small effect is multiplied by many uses, producing a large consequence.

Whenever I have been able to trace management action subsequent to the loss, I have found that the universal pattern continues. After the failure is spotted:

9. Management's first reaction is to minimize its magnitude, so the consequences are continued for somewhat longer than necessary.

10. When the magnitude of the loss becomes undeniable, the programmer who actually touched the code is fired—for having done exactly what the supervisor said.

11. The supervisor is demoted to programmer, perhaps because of a demonstrated understanding of the technical aspects of the job. [not]

12. The manager who assigned the work to the supervisor is slipped sideways into a staff position, presumably to work on software engineering practices.

13. Higher managers are left untouched. After all, what could they have done?

The First Rule of Failure Prevention
Once you understand the Universal Pattern of Huge Losses, you know what to do whenever you hear someone say things like:

• "This is a trivial change."

• "What can possibly go wrong?"

• "This won't change anything."

When you hear someone express the idea that something is too small to be worth observing, always take a look. That's the First Rule of Failure Prevention:

Nothing is too small to be unworthy of observing.

It doesn't have to be that way
Disaster stories always make good news, but as observations, they distort reality. If we consider only software engineering disasters, we omit all those organizations that are managing effectively. But good management is so boring! Nothing ever happens worth putting in the paper. Or almost nothing. Fortunately, we occasionally get a heart-warming story such as Financial World telling about Charles T. Fisher III of NBD Corporation, one of their award-winning CEO's for the Eighties:

"When Comerica's computers began spewing out erroneous statements to its customers, Fisher introduced Guaranteed Performance Checking, promising $10 for any error in an NBD customer's monthly statement. Within two months, NBD claimed 15,000 new customers and more than $32 million in new accounts."

What the story doesn't tell is what happened inside the Information Systems department when they realized that their CEO, Charles T. Fisher III, had put a value on their work. I wasn't present, but I could guess the effect of knowing each prevented failure was worth $10 cash.

The Second Rule of Failure Prevention
One moral of the NBD story is that those other organizations do not know how to assign meaning to their losses, even when they finally observed them. It's as if they went to school, paid a large tuition, and failed to learn the one important lesson—the First Principle of Financial Management, which is also the Second Rule of Failure Prevention:

A loss of X dollars is always the responsibility of an executive whose financial responsibility exceeds X dollars.

Will these other firms ever realize that exposure to a potential billion dollar loss has to be the responsibility of their highest ranking officer? A programmer who is not even authorized to make a long distance phone call can never be responsible for a loss of a billion dollars. Because of the potential for billion dollar losses, reliable performance of the firm's information systems is a CEO level responsibility.

Of course I don't expect Charles T. Fisher III or any other CEO to touch even one digit of a COBOL program. But I do expect that when the CEOs realize the value of trouble-free operation, they'll take the right CEO-action. Once this happens, this message will then trickle down to the levels that can do something about it—along with the resources to do something about it.

Learning from others
Another moral of all these stories is that by the time you observe failures, it's much later than you think. Hopefully, your CEO will read about your exposure in these case studies, not in a disaster report from your office. Better to find ways of preventing failures before they get out of the office.

Here's a question to test your software engineering knowledge:
What is the earliest, cheapest, easiest, and most practical way to detect failures?

And here's the answer that you may not have been expecting:

The earliest, cheapest, easiest, and most practical way to detect failures is in the other guy's organization.

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

Cases such as those cited above are in the news every week, with strong impact on the general public's attitudes about computers. But they seem to have no impact at all on the attitudes of software engineering professionals. Is it because they are such enormous losses that the only safe psychological reaction is, "It can't happen here (because if it did, I would lose my job, and I can't afford to lose my job, therefore I won't think about it)"?

(Adapted from Responding to Significant Software Events )
http://www.smashwords.com/books/view/35783

Resolution #2 for the new year

2010-12-30T23:00:00.001-08:00

Not just by writing, do more to help humanize computer business–a long way to go: <http://www.smashwords.com/profile/view/JerryWeinberg>

See this Amp at http://amplify.com/u/k4ix

Resolution #1 for the new year

2010-12-30T22:51:00.001-08:00

New Year Resolution #1: Make all my writings available in all eBook formats, so I'm free to write some more novels, stories & non-fiction. <http://www.smashwords.com/profile/view/JerryWeinberg>

See this Amp at http://amplify.com/u/k4hx

n Gratitude of Gratefulness

2010-12-24T10:38:00.001-08:00

Amplify’d from www.tommyangelo.com

6 Comments

In Gratitude of Gratefulness

Posted by: Tommy Angelo on December 24th, 2010

“Finish your food! Think of the starving children in China!”

That was a typical thing for parents like mine to say to kids like me as I poked at the mucoid vegetables on my plate.

“Think of the starving children in China.”

That saying failed utterly at its purpose. All it did was make me resent the alleged starving Chinese children as much as I resented being forced to eat snot. And the resentment was just getting warmed up. For the next few decades, when someone said something about how I should be grateful or thankful or whatever, I resented them for even suggesting such a thing. First, I always had lots of problems: work problems, money problems, car problems, friend problems, lover (or lack of lover) problems, etc. I kept track of and organized my problems. You want me to be thankful? Have you seen my list of problems lately?
Read more at www.tommyangelo.com

See this Amp at http://amplify.com/u/jfcz

The Parable of the Ones

2010-12-24T10:11:00.000-08:00

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

2010-12-09T10:56:00.000-08:00

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

Twitter 101

2010-11-30T14:05:00.001-08:00

If you're new to Twitter, or intimidated by it, start here.

Amplify’d from www.yorkwriters.com

Twitter 101: A Beginner’s Guide for Writers (and Other Creative People)

Twitter 101: A Beginner’s Guide for Writers (and Other Creative People)
Read more at www.yorkwriters.com

See this Amp at http://amplify.com/u/gxdm

Technical Debt && Collins' Stages of Decline; OR, The Exponential Point of No Return

2010-11-19T22:31:00.001-08:00

URL: http://www.financialagile.com/reflections/9-general/45-...

Collins model goes something like this:

* Stage 1 - Hubris Born of Success.

* Stage 2 - Undisciplined Pursuit of More.

* Stage 3 - Denial of Risk and Peril.

* Stage 4 - Grasping for Salvation (AKA Panic).

* Stage 5 - Capitulation to Irrelevance or Death.

Now, tie this to software ...

See this Amp at http://amplify.com/u/foy1

Sometimes Perception Is the Problem By Payson Hall

2010-11-17T07:59:00.001-08:00

URL: http://www.stickyminds.com/testandevaluation.asp?Functi...

Summary: High on a mountain twenty years ago, a wise man shared secrets of problem solving that have served Payson Hall ever since. In this article, Payson passes along a simple definition that offers insights into problems and potential solutions.

See this Amp at http://amplify.com/u/fgea

Along with The Art of War, I read this book 3-4 times a year.

2010-11-15T21:04:00.001-08:00

http://www.scribd.com/doc/42712109/Secrets-of-Consulting-a-Gui...

Why? Because I keep falling back to the silly state I was in before I first read them.

See this Amp at http://amplify.com/u/fayj

2010-11-14T11:33:00.001-08:00

Review of First Stringers, from LibraryThing.com Weinberg has produced a delightful book that kept building both in story and in character development as you progressed. The processes of ferreting out the puzzle pieces with the characters as the adventure took them out of their comfort zones is exhilarating, and just when you think you see the outline of the picture the author brings in new characters and information to make you start all over again. Adventure. Mystery. And something … unusual. http://amplify.com/u/f7ur

The Sauerkraut Syndrome

2010-11-11T22:48:00.000-08:00

There are quite a few consultants in the over-40 category, and that they tend to be well paid. In this post, I want to speak to some of my older compatriots about what their role is, other than just banking those big bucks. And then I’ll conclude with a few words to my younger colleagues about how to deal with us old fogies.

One thing that we old folks can do is tell stories that the young ‘uns can’t match—about such things as paper tape, relays, mercury delay lines, and sauerkraut. Sauerkraut?

Well, it’s this way. Back in the Summer of ‘49, I was on the picnic/softball circuit in Omaha, and during a game against the Tigers, I ate some sauerkraut in the bottom of the fourth inning. In the bottom of the eighth, I stretched a single into a double, sliding head first into second base—and throwing up all over the second base bag.

It was a summer to remember. The good part was that we beat the Tigers three times and won the championship. The bad? I had sauerkraut twice more and threw up both times—once behind the bench and once, as I gained more experience, under the bleachers.

Recently, I was telling some young software maintainers and their boss, Ted, about that Summer of ‘49, and Thurman asked, “Does sauerkraut still make you sick?”

“I don’t rightly know, young feller,” I honestly replied. “I haven’t et any in 50 years.”

“Oh,” Thurman said. “You should try some again. Maybe now it wouldn’t make you sick.”

“Could be,” I opined, “but I don’t see the benefit in trying. As I recall, I didn’t fancy sauerkraut all that much to begin with.”

I told a few more scintillating stories, and then we got back to work, trying to get a thorny maintenance bramble under control. At a certain point, Thurman suggested that Ted offer the maintenance programmers to opportunity to try what I call “worst-first” preventive maintenance. The maintainers would identify one component of the system that caused the most maintenance headaches, and it would be rewritten, to reduce maintenance problems.

Ted, who was showing small touches of gray around the temples, said, “I’ve seen that technique tried, and it didn’t work. The new component was just as buggy as the original, so the development effort was wasted. Since it was my idea, the management decided they would let me go. No, I’m not going to try that again.”

“So,” Thurman pitched in, “to you it’s like sauerkraut.”

“What do you mean,” Ted asked, a befuddled look on his wrinkled face.

“Well, Jerry tried sauerkraut a long time ago and it didn’t sit very well, so he’s never tried it again. Just like you and worst-first maintenance.”

Can you see now why we old guys hate you young whipper-snappers? Nobody likes to hear the truth about how they’ve aged and changed from innovators to arch-conservatives, victims of the Sauerkraut Syndrome, which works inside our heads like this:

“I’ve tried that before and gotten punished. The potential payoff for me in trying again isn’t big enough compared with the possibilities for punishment. So, I’m not going to try it again.”

The Sauerkraut Syndrome is a perfectly reasonable attitude for the older contractor. What’s not reasonable is for us old geezers to stand in the way of younger people who want to try something different. For one thing, some things do change in fifty years, or twenty, or even two. For another, the payoffs are different. Thurman has a long career ahead of him—a lot of time to recover—and a great need to get some experiences under his belt.

So, you ask, what are we old folks supposed to do when one of our younger colleagues comes up with ideas they think are new, but we’ve tried before and regurgitated? How do we break the Sauerkraut Syndrome? Here are some suggestions:

- We can keep our mouths sealed against the temptation to say, “That’s not new. I tried that back in the Depression.”

- We can keep out of the way, letting them learn from their own mistakes, or their own triumphs. For learning, nothing beats doing it your own way so you have nobody to blame if your idea doesn’t work out.

- We can be emotionally supportive. In case you’ve forgotten, youth is a highly volatile time, and sometimes it helps to have someone around who lets you know that the world isn’t about to end, regardless of how it seems.

- We can refrain from saying “I told you so” if the idea fails this time. This doesn’t help anybody, and it doesn’t make friends.

- We can admit our fears and suggest slight modifications to the idea that will help reduce them or increase our own payoff. Ted might have said to Thurman, “I’d like to try that, but we all know that the worst component right now is also the most critical, and I’m afraid that modifying it will make it worse. How about testing your idea first with a component that’s not quite so critical, to show that we really know how to rewrite a component and actually improve it? Maybe we can try that Scrum business you're always bleating about.”

- We can refrain from giving advice, especially if it’s not asked for. Advice can undermine the confidence of the receiver—if it works, it can make the receiver feel inadequate for not knowing without advice; if it fails, it can make the receiver feel stupid for listening to you. If you must give advice, give it to your fellow old folks, the way I’m doing now.

- We can move in and grasp the young colleague’s new idea if it starts to work. Ideas need time to work out their glitches, and there’s nothing quite like an older, supposedly wiser, person saying, “Oh, now I see what you’re doing. Cool!”

As for you young folks, if you’ve gotten this far, you can return our support by being a little forgiving when we forget your name, or our own telephone number, or seem frightened by your perfectly innocent and reasonable idea.

And, you can politely ignore us if we offer a little unsolicited advice that you don’t care to hear.

And, finally, you can remember this advice that was once given to me by someone even older than I am:

When an old engineer tells you something is possible, believe it.

When an old engineer tells you something is impossible, disregard it.

p.s. If you'd like to learn more about inventions and how old and young engineers kick them around, take a look at the first couple of books in my Aremac series of novels. They can be purchased as eBooks for only $4..99 each, The Aremac Project and Aremac Power. You can even get one for free (Jigglers) at http://www.smashwords.com/books/view/22171. Or, buy the paperback versions on Amazon.com or other retailers.

A Code of Work Rules for Consultants

2010-10-29T10:55:00.001-07:00

I frequently meet a consultant who is deeply troubled by the implications of the work of a consultant. What we do today may affect the lives of thousands or millions of people for many years to come.

Moreover, most of those people we affect won't have any way to relate a discomfort in their lives to what we are doing today.

They will, perhaps, sheepishly accept the explanation, "That's the way the computer must do it," or the even more insidious, "that's the way things are."

Some consultants I know, particularly those working in shops where nobody ever looks at anybody else's work, salve their conscience by sabotaging their client's information systems.

In many cases, it's difficult to tell whether this is intentional or unintentional. In other cases, there is no doubt.

Many programmers, analysts, and consultants have complained to me that their work holds no meaning for them. They don't know what is being done with the piece of design or specification they work on, or they know and don't approve.
Their response is to stay on the assignment, draw their fee, and badmouth their client at every safe opportunity.

I think it's time we stood up to be counted. We have an enormous responsibility to the people whose lives will be impacted by the organizations we work for.
If we don't believe in what our client is doing, or we don't understand it, then why are we working there? To draw a fat fee? Then what does that make us?

For some years now, I've been giving a set of principles to consultants who are seeking a new assignment, or are considering changing their present assignment because of such doubts.

In recent years, as the job market shrinks, the number of such doubters seems to be increasing so I thought that many professionals would like to see these principles written down:

1. I will not work for an organization whose goals are not consonant with my beliefs.

2. I will not work on projects whose goals I do not understand, or cannot agree with.

3. Before becoming part of a project, I must ﬁrst obtain agreement on what percentage of my time I can (and must) spend on continuing professional development, and what resources will be provided me for that purpose.

4. I will not work under measurement schemes that pit one person's performance against another's. Rather, I will co-operate totally to help others in the project achieve their full potential, as I expect them to help me do.

5. I will not accept work without understanding what is to be done, and why. Nor will I pass work to others without their similar understanding.

6. All my work will always be open and available for critical comments (circumscribed, as appropriate, by security considerations). Furthermore, I will always stand ready to review the work of others in exchange for them returning the service to me.

7. As long as the above conditions are met, I will devote myself in the utmost to achieving the goals of my client and their project.

Over the years, I've found that people who ask these questions and set those conditions don't wind up in jobs that make them miserable. Sometimes, when they ask them honestly they leave their present position for something else that makes them happier, even at a lower fee scale.

Sometimes, a client manager is outraged at one of these conditions, which is a sure indication of trouble later, if not sooner.

Many of us lost souls need some guidance, and it might have been easier to have a set of principles when the job market wasn't so tight. But over the years, I've learned that consultants following these principles are more successful at landing good contracts–ones that make them richer and, more important, happier.

The Fundamental Regulator Paradox

2010-10-25T20:53:00.001-07:00

Read all four articles, but esp. these and the following paragraphs:

Amplify’d from www.developsense.com

Blog: Project Estimation and Black Swans (Part 4)

So: we can’t predict the unpredictable. There is a viable alternative, though: we can expect the unpredictable, anticipate it to some degree, manage it as best we can, and learn from the experience. Embracing the unpredictable reminds me of the The Fundamental Regulator Paradox, from Jerry and Dani Weinberg’s General Principles of System Design which I’ve referred to before:

The task of a regulator is to eliminate variation, but this variation is the ultimate source of information about the quality of its work. Therefore, the better job a regulator does, the less information it gets about how to improve.

This suggests to me that, at least to a certain degree, we shouldn’t make our estimates too precise, our commitments too rigid, our processes too strict, our roles too closed, and our vision of the future too clear. When we do that, we reduce the flow of information coming in from outside the system, and that means that the system doesn’t develop an important quality: adaptability.
Read more at www.developsense.com

See this Amp at http://amplify.com/u/dzht

Mnemonics

2010-10-11T10:22:00.000-07:00

How do you remember things?

I remember pi with a little poem I created some forty years ago:

C over D

Yes. I have a trick, sequences to recall,
Using one plain mnemonic faultless ordinal,
Breaching all of the barriers that retain pi–
Bereft, will all lax thinkers die,
By circles overborne?

(Pi to 30 digits, with the decimal point and a question mark at the end signifying there's more to come.)

So, how do you remember things?

Give us a comment, so we can improve our memories, too.

Or would you like a machine that replays movies of your memories?

The Aremac does that: Read:
The Aremac Project in Paperback
The Aremac Project as eBook

A Workshop to Remember

And remember, the Problem-Solving Leadership Workshop (PSL) is coming in May, and fills up fast. So tie a string around your finger, or visit my website

Rumors of My Quitting Are Grossly Exaggerated

2010-10-01T22:29:00.000-07:00

InfoQ's website ran an essay that said:

"Now he doesn't do that much in software anymore, he writes science fiction [and] he runs his AYE Conference, which is a human potential kind of conference."

I tried to reply, but their reply function crashed on me, so I'm putting my response here, to clear things up:

Gee fellas and gals,
Well, I was slowed down for a year while beating "incurable" cancer. bit how many of the rest of you have published even one book on software in the past two years? (I've done several.)

If that isn't "much," then how about my Problem-Solving Leadership Workshop (PSL), or my keynotes at software conferences? And AYE is principally for software folks, just like your website. Isn't your website "doing much"? (I think it is.

And, then there's consulting. Don't my clients think they're doing software?

Maybe my novels are confusing you (and others). They're entertaining stories, to be sure (at least I think so, but see for yourself). But they are full of s/w lessons--just another one of the ways I'm trying to get these lessons across. You know as well as I how hard that is. So, after 50 years, I decided to try something new--in ADDITION to my other activities--books, essays, blogs, workshops, conferences, consulting--AND responding to other people's blogs, like right now.

Thanks for listening. - Jerry Weinberg

Visit my website if you'd like to know more about what I've been doing.

Have S/W Projects Hit a Wall?

2010-09-22T13:31:00.000-07:00

I recently received an interesting set of questions about software projects from a French science journalist. I thought my readers would like to see those questions and my answers, so here goes:

Q: Do large software projects fail at a rate significantly higher than other engineering projects in physical world (also quite complex!)

A: Well, as far as total failure, yes, I think s/w projects fail totally more than, say, building ships.

OTOH, the US Navy reported a few years ago that every ship built since World War II has been late and over budget, so that type of "failure" is 100%, even though we've been building ships for hundreds of years. The Wasa (or Vasa) Ship in Sweden is a good historical example of one reason for failure: the piling on of requirements until complexity is too great.

See http://en.wikipedia.org/wiki/Vasa_(ship)

Q: Do we know exactly why ? Is it a management problem or theoretical problem ?

All the failures I have studied have been management failures. In some cases, the theory might have been wrong, but management failed to notice the signs of impending failure, or noticed them but failed to act in time to prevent the project from becoming a death march.

Q: Have we reached now a critical size of dependable verifiable code, something like a "wall of complexity" ?

A: Such a wall definitely exists, though its thickness is somewhat fuzzy. Some well-managed projects can surpass the "wall" that stops poorly managed projects. But eventually, at any given state of the art, there will be a "wall," and as the project approaches its particular wall, progress becomes sluggish and expensive. When that happens, good managers recognize what's happening and take action--generally pulling back on some of the excess "requirements."

Q: Does it mean that "Internet of things", or other big things "real time" (like FAA air traffic) we would like to build with high reliability, are not really possible for the moment?

I first worked with the FAA in the late 1950s, trying to help them build the air traffic control system of their dreams. It wasn't possible then to implement their dreams, and it's still not possible. Why? One reason is that their dreams keep growing faster than our ability to implement them. They could build a better system, but when they try to build "the best system for all time," they collapse like the Wasa Ship.

Q: Is there a lack of a theory of building large-scale software (like rules governing civil engineering in physical world) ? Is it because computer science is still a relatively young science ?

A: There is a total lack of theory, but there are some empirical principles gained from experience. I've tried to catalog these principles in my Quality Software Management series (see below).

The trouble with computer science is that it's not a science, but generally a kind of mathematics without connection with the empirical world.

Rules governing civil engineering come largely from real-world experience, followed up by some scientific work in a few areas, like the properties of building materials. In computing, much of what we do know is simply not know to most developers, who are too busy trying to salvage poorly managed projects.

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

So, how do my answers compare with yours. Am I feeling too pessimistic, or optimistic?

Why Do You Charge So Much?

2010-08-25T22:27:00.000-07:00

Randolph's Tough Question

Randolph is one of the sharpest technical consultants in my network. Until yesterday, I'd have bet a hundred bucks that no client could stump him with a question - but I'd have lost.

When Randolph called for a bit of meta-consulting, he was so nonplussed I had to spend three whole minutes in idle chitchat, which wasn't Randolph's usual no-nonsense style. Finally, I couldn't stand the suspense, and I asked, "What's the matter, Randolph?" (Nobody calls him "Randy" more than once. It's Randolph all the way.)

"Why do you charge so much?" He blurted so quickly I didn't believe I'd heard him.

"Say what?"

"Why do you charge so much? That's what he asked me!"

"Who asked you?"

"My client. The new one."

"So what did you tell him?"

Pause. Sigh. Longer Pause.

"Randolph? Are you still there?"

Pause. Finally a weak voice said, "I didn't know what to tell him. That's the problem."

I recognized the problem and tried to reassure him. "Randolph, you're not the first consultant who's been stumped by that question. And you won't be the last."

"But I've got to go back there tomorrow, and I don't have an answer. I need help."

Turning the Question Around

Well, yes, Randolph did need help, and perhaps you do, too. Do you hesitate and stammer when your client asks this dreaded question? Are you ashamed to explain to your employee friends who make one-third of your hourly rate? Do you feel guilty that you make so much more than your spouse, who works much harder than you? And how do you handle yourself when the IRS asks you the same question? Well, I'm your meta-consultant, and unlike your IRS agent, I'm really here to help you.

First of all, I'm going to advise you to meet this question head-on by turning it around. Instead of emphasizing how much you're getting, emphasize how much they're getting. Many clients are unclear as to just what they get in return for your fee. This is not surprising, as your fee covers a wide range of intangibles. That's why you need to break out the various components, which I've done in simple ABC format so you can remember next time you're put to the question:

A. Attention. I suspect my clients would be astonished to discover how much time I spend thinking about them and their problems when I'm not "at work." I might be hiking in the woods, or reading a magazine, or taking a shower, and a thought comes to me about something that will help my client. For example, I was driving back from Los Alamos last week and suddenly realized that I'd spent the whole distance from Jemez Springs to Corrales working out a transition plan for a client in Ohio. I could have been enjoying the enchanting scenery - and perhaps I was. But most of my conscious mind was in Cleveland, developing the plan. Supper had to wait until I had the details in my Mac.

And that's just conscious attention. I don't know about you, but I often dream about my clients' problems, often awakening in the middle of the night with solution ideas. This happens so frequently, I keep paper and pencil handy on my headboard, where I've mounted a high-intensity lamp that won't awaken Dani when I'm scribbling away at three in the morning.

B. Barring Competition. While working with one client, I won't work with a client who competes directly with them in the area I'm working. This exclusivity sometimes reduces my opportunities for paying work, but clients may take this service for granted if I don't point it out to them.

C. Celebrity. As my reputation has grown, I've noticed that my clients are quite willing to use it to sell their product or programs within or without the company. They may not be aware that this use of my reputation creates a risk for me. If they make a mess, some of the dirt rubs off on me.

Ah, I've now run through ABC, but there are more items in this alphabet.

D. Dexterity. My clients unconsciously expect me to be on call, not only for the planned activity, but also for unexpected emergency jobs, incidental questions, idle speculation, and all sorts of administrative work such as rescheduling at their convenience. Moreover, unlike their employees, I get neither sick days nor vacation days. When I say I'll be there- and sometimes when I haven't said - I'm there. Even when I'm not there, I've implicitly or explicitly restricted my other activities so I'll be able to respond to their needs in a reasonable time.

Moreover, although I don't get sick leave, and I don't participate in their health benefits, I'm often expected to work under pressure, at odd hours, in inaccessible locations - all the while operating at top efficiency.

E. Education. Speaking of top efficiency, my clients don't pay directly for all the education I bring to the job - not just my formal education, but, for example, the thousands of hours I spend reading in related fields. I figure that in a typical year, I read the equivalent of two books a week, perhaps more. Very few of their employees devote this kind of personal time to their own development. And, when they take a seminar or attend a conference, their employer pays for them - but not for me. (Well, sometimes they do, if it's directly related to their problem and nobody else's.)

F. Flexibility. My clients can release me in a minute if they no longer need my services. Even in these days of downsizing, they don't have this cheap kind of flexibility with their employees.

G. Gratuity. Although I may charge clients for out-of-pocket costs, such as transportation and hotel rooms, I don't charge for meals, supplies, reasonable phone calls, faxes, mailing, and so forth. All these gratuitous expenses save paperwork for my clients, and they're lumped in with my other overhead - my own office space, utility bills, computers, software, network services, professional services, and the like.

H. Honesty. The work I do for my clients can sometimes literally mean the life or death of a project or campaign. This is a grave responsibility, and I accept it fully and do whatever is necessary to give full value. And, unlike an employee, I offer my clients a money-back guarantee of satisfaction with my work.

I. In-house Labor. Nowadays, most consultants/contractors are paid by the hour, or sometimes the day or week. This method of payment tends to emphasize a single tangible component of what my client is getting - my face time toiling on their premises. If they look at me as simply another grunt, grinding away in their office, no wonder it's hard for my clients to understand why my apparent rate is larger than that of their typical employee. They're missing all the other letters of the alphabet.

ZZZZZ. Sleep. Of course, I do have to sleep once in a while - and, unlike some of their employees, I'm not charging them for this. Even when I dream about them.

So there you have it, my Abecedarian cheat sheet that will prevent both you and Randolph from ever again being stumped by a client's question.

Amplify Experience

2010-08-22T20:50:00.001-07:00

The last two times I've tried to clip an interesting web page, Amplify has failed me. Most recently: http://tinyurl.com/2f98zku So, go there yourself and have a read. http://amplify.com/u/92fe

(two days later)

Encouraged by Amplify's president, I made a few changes and tested Amplify again.

So, with a little help from president Goldstein, I now have Amplify working again. It's a fine idea.

If you don't know about the app, look up his article, "What’s the need for Amplify?"

And, after all, I'm host at the Amplify Your Effectiveness Conference (AYE Conference), so I'm all for amplification of effectiveness, which Amplify helps me do.

How to get a job or assignment

2010-08-19T21:44:00.000-07:00

One of my colleagues recently wrote about her difficulty in landing consulting assignments. She has some great unique models, but, as she says, ...

The Problem

Most large companies (w/ no R-D labs) have the resources to take risks but refuse to.

Small companies have the guts to take the risks, but do not have the resources or the macro set of processes to do it. ...

What do you think?

Some Solution Ideas

It's one of the paradoxes of the consulting business.

Sometimes, the trick is to choose medium-sized companies. :-)

Seriously, people retain your services only when they know you enough to trust you. Consequently, my preferred method has always been to have a stepped-variety of offerings so they can start to know me in safe, tiny steps (books, keynote addresses at conferences, blogs, comments on blogs, ) ...

Then have medium steps (like workshops, tutorials at conferences, ) ...

Then larger steps (consulting visits)

Then really big steps (consulting contracts ).

Then retire rich.

Solution Ideas for Getting Hired on a Job

These days, it's not just consultants who are having a hard time finding the work they want. In the same mail, I got the following email from Liam, a recent PSL grad:

"As you were advising me to start looking for a new job in the Spring of '09 at PSL, you won't be surprised that lost my job at XYZ at the end of last year."

Not surprised, but disappointed. Still, in the long run, these changes usually work out for a much better situation. Losing the job is just confirmation of a lousy situation.

"I am still looking and would welcome any ideas or advice you might have."

The Problem of Getting Hired on a Job

Well, I just finished an email to another grad who's trying to establish his consulting business (which is getting a number of jobs, so there are many similarities). I'll quote what I told him:

Sometimes, the trick is to choose medium-sized companies.

***[Liam: this might apply to job-hunting, too. In any case, whatever you're doing now, change something--bigger, smaller, more or less medium, you know.]

My preferred method, though, has always been to have a stepped-variety of offerings so they can start to know me in

- tiny steps (books, speeches at conferences, blogs, comments on blogs, ) ...

- Then have medium steps (like workshops, tutorials at conferences, ) ...

- Then larger steps (consulting visits)

***[Liam: interview visits, but also visits to help you show off by
doing something for them that's specialty of yours, just a talk, maybe]

- Then really big steps (consulting contracts).

***[Liam: hiring, which is a really big step these days, so perhaps hiring for a trial period, to minimize their risks]

Then retire rich.

Applying My Own Advice

Well, I'm already rich, haven't wanted a "job" for half a century, and have more consulting requests than I can handle. BUT, I'd like to be "hired" more often in my new "career"–writing fiction that entertains while teaching, or teaches while entertaining. I'm trying to apply my own advice to this new situation:

- tiny steps (books, speeches at conferences, blogs, comments on blogs, ) ...

***[Jerry: A book is already "tiny" for your consulting business, but in the book business, that's it! Well, no it isn't, so I'm trying to make samples available (see one example below in the Appendix, my email signature, which is another tiny step) ]

- Then have medium steps (like workshops, tutorials at conferences, ) ...

***[Jerry: I offer workshops and tutorials for writers (writers are a small part of my potential audience, yet can be quite influential). I set up a book table at conferences, where people can actually put their hands on books. I've tried book-signings, but they're pretty painful when nobody shows up. And larger samples.]

- Then larger steps (consulting visits)

***[Jerry: I haven't really figured out how to do this. Well, I've just become a member of Book View Café, a writers' cooperative, where I have serialized one of my books for free, and will blog pretty regularly http://www.bookviewcafe.com]

- Then really big steps (consulting contracts).

***[Jerry: I've had some offers to write books-for-hire, but that's too much like a job. I suppose I'm fantasizing that some huge publisher will see one of my books and offer to make it into the next Harry Potter, but that's just a fantasy. And if they offer me a movie option, I'll turn it down. I used to live near Hollywood, and the smell of it was more than enough for me. (but I do love going to movies, but I saw what they did to the book of a friend of mine--and no thanks. He now wears a t-shirt that says, "Don't judge a book by its movie.")]

Then retire rich.

***[Jerry: You already did that, so take $$$ out of the equation. Write for fun, but get as many readers as you deserve, neither more nor less.]

A Cry for Help

After sending those two replies to my students, I immediately realized I had failed to mention the most important possible solution. (Isn't that what always happens when you hit the SEND button? Maybe I should sell SEND buttons to writers who need inspiration.]

What's that solution idea? Obviously:

- ask your friends for solution ideas.

So, friends, any ideas for my fiction business?

- And, oh, yes, you can ask your friends for jobs/assignments.

So, friends, I wouldn't object if you bought a book or two.

- Motivate them, or why would they want to do it.

Well, I believe my books ought to be self-motivating, but I have to motivate potential readers to actually look at them. So, perhaps because you know my non-fiction, or my teaching, you might be motivated to buy one of my books (either e-book or paperback). And, if you read it, and don't like it, I'll personally refund your money.

But if you do like it, I wouldn't object at all if you told me, and even wrote a review of it for Amazon, Smashwords, Powell's, your blog, or any other place that accepts reviews. If you do, I'll give you the free book of your choice, as a small thank you. Heck, I'll even give you your money back, if that's what you prefer.

And, yes, I really mean it.

Appendix: My Email Signature Inviting Sampling

How to sample my novels (try before you buy):

Suggestion: Go to the CreateSpace website for each of the books below and see a short description of the book.

Or, if you want a sample, click on , then click on a title you're interested in sampling, then "buy" the book and ask to see the sample.

Or, for most of the books (not fully updated yet) you can read smaller samples on my website (below).

http://www.geraldmweinberg.com/Site/eBOOKS.html

Or, if you prefer them as quality paperbacks:
First Stringers: https://www.createspace.com/3463980
Second Stringers: https://www.createspace.com/3464933
The Hands of God: https://www.createspace.com/3466119
Mistress of Molecules: https://www.createspace.com/3390916
Freshman Murders: https://www.createspace.com/3469259
The Aremac Project:
Aremac Power
Earth's Endless Effort