Wednesday, December 14, 2011

Change Artist Challenge #10: Learning from History

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.


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


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.


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.


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.


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.


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

Tuesday, December 06, 2011

Disposable Programs (Part 2)

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 figures, contingent prices are given, reflecting 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 first.

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 first use.

At first, 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 figurative. 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.

Wednesday, November 30, 2011

Disposable Programs

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 five examples relative to your own experience, you will notice two categories:

KEPT: first-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 infinite 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.

Thursday, November 24, 2011

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

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?

Tuesday, November 22, 2011

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

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

Thursday, November 10, 2011

Iterative Development: Some History

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.

Monday, October 24, 2011

Challenge 9: Organizing The Grand Tour

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

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

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

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.


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

Thursday, October 20, 2011

Review: September issue of Tea-Time for Testers

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

Tuesday, October 18, 2011

Trying to Change a Dysfunctional Organization

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.

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.

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

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.

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

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


- The new scenario revealed a bug.

Was anyone surprised by this?

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

Was anyone surprised by this?

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

Was anyone surprised by this?

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.

Meaning the manager had already done design work?

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

Was anyone surprised by this?

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.

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.

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

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!

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

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.

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.

You have to find others who see things that way.

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.

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.

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.

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

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.

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

Hope this helps.

Thursday, October 13, 2011

Switching Topics at Conference Presentations

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

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:

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



Sunday, October 09, 2011

Moving Through Molasses

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:

• Amazon Store:

• Apple Store:

• Smashwords Store:

Wednesday, October 05, 2011

Medium-number Systems

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.

Wednesday, September 21, 2011

Why English Will Never Be 100% Automated: Example

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

Saturday, September 17, 2011

Downgraded to Testing

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.

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.


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

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.

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

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.

Anyway I will not stay long there anymore.

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

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

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.

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.

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.

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.

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.

Responding to Significant Software Events

How to Observe Software Systems

Friday, August 26, 2011

Change Artist Challenge #8: Applying The Principle of Addition

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.

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.

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 <> for links to all of my books at the major vendors.

Monday, August 22, 2011

We're not so smart, or strong

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

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


Saturday, August 20, 2011

Size Does Matter in Space!

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

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.


Thursday, August 18, 2011

Change Artist Challenge #7: Being Fully Absent

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

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.

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 <> for links to all of my books at the major vendors.

Friday, August 12, 2011

Persistence in Problem Solving

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?"


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:


(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

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.


Wednesday, August 10, 2011

What's Wrong with Agents as Publishers?

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

Should Agents Publish? (Writers Beware!)


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.

Friday, August 05, 2011

Change Artist Challenge #6: Being Fully Present

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.

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.

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 <> for links to all of my books at the major vendors.

Monday, August 01, 2011

Make sure of your writing heritage

Please do not ignore this essay. Please.

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.

Friday, July 29, 2011

A Universal Starting Point for Problem-Solving

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?

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.

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.

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!"

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.