Overconstraint: Some Effects on S/W Design

Continuing my weekly excerpt series, the following sections are taken from Exploring Requirements, Volume 2: First Steps to Design

16.5 Overconstraint

Relaxing a constraint increases the size of the solution space, and therefore may increase the number of potential solutions. Conversely, tightening a constraint decreases the size of the solution space and may eventually result in an overconstrained set of requirements. In this event, finding any acceptable solution would be very difficult, or even impossible.

It will certainly be impossible to find a solution if there are conflicting constraints, as when one constraint says Superchalk must be longer than four inches and another says it must be shorter than three inches. If you attempt to sketch this solution space, you'll find it has zero area.

Even when the solution space doesn't have zero area, it may still be impossible to find any real solution possibility falling within it. Of course, this unfortunate condition won't become apparent until design. Experienced designers, though, can often guess what is happening, especially as they watch the solution space shrinking.

If the solution space is actually void of possible solutions, you will have to negotiate one constraint against another. If you can't do that, you'll have to drop the project. There are worse things than dropping a project in the requirements stage, such as dropping it in the post-implementation stage. So be on the lookout for an empty solution space, and don't be afraid to suggest termination if it's clear the project is overconstrained.

It's extremely important when and how you suggest termination. Sometimes people are implicitly pre-negotiating constraints, because they have an image of the system becoming overconstrained. For example, they won't mention something they really want, or they'll start trying to suppress someone else's idea.

Einstein once said, "A theory should be as simple as possible, but no simpler." We can paraphrase Einstein and say,

Requirements should be as constrained as possible but no more constrained.

Applying this principle is equivalent to saying,

The solution space should be as large as possible, but no larger.

That's why it's a much better idea to deal with constraints explicitly.

16.6 Psychology of Constraints

Mathematically, we know excessive constraints limit the size of the solution space, but even worse, they limit us psychologically.

16.6.1 The tilt concept

If you watch people play pinball, you'll notice some of them tilt the machine occasionally, while others never tilt. The ones who tilt too much are not good players, because they are unable to restrain themselves. But the ones who never tilt are terrible players, because they restrain themselves excessively. Why? Because tilting shows the players just how far they can safely bump the machine. If you never exceed your limits, you never learn what your limits are. So, this is the tilt concept:

If you never tilt, you don't know if you're using your full resources.

As designers, we are often intimidated by constraints. We toss out an idea, then:

• Someone says, "That information is confidential," so we stop pursuing an idea which may be essential to a superior design.

• Someone points to a seven-foot shelf of standards manuals and declares, "Doing what you propose violates our standards," so we drop a promising idea.

• Someone frowns and whispers, "The boss would never approve of what you're proposing." Even though it's merely an idea for a brainstorm, and not a proposal, we shrivel into a ball and change the subject, never daring to check it out.

Much of the time, most of us tend to operate at some safe distance from the constraint boundaries, because we're afraid of tilting something. Thus, none of us search the entire solution space, but only a reduced solution space, as suggested in Figure 16-8.

Figure 16-8. Most designers don't search the entire solution space, but merely a reduced solution space determined by their fear of constraints.

16.6.2 Breaking constraints

You can always overcome this limitation by probing politely, but firmly. At one of Jerry's clients, the requirements team indicated the product had to be shipped by November 1. As this seemed an impossible overconstraint, Jerry asked, "Where does that date come from?" Everybody in the room got a shocked and frightened look, and one man lowered his voice and said, "The boss told us."

If Jerry didn't understand the tilt concept, he would have become just as frightened as they were—and dropped the subject. But he was an outsider anyway, so he asked for a break and went down the hall to talk to the boss. "There seems to be some uncertainty in the other room," he said. "What deadline did you set on this project, anyway?"

"November 1."

Jerry might have stopped there, too, but the tilt concept kept him going, "That date may turn out to be an overconstraint. Can you explain where it comes from?"

The boss looked a little puzzled. "Constraint? I didn't mean it to be a constraint. They asked me when I wanted it, so I said it would be nice to have it by November 1. I didn't want it after November 1 because it would interfere with our year-end processing, but after January 15 would be just fine. Heck, as long as I get it by June there won't be any problem."

In other words, there was a hole in the solution space, between November 1 and January 15, but there was plenty of solution space on the other side of the hole.

When Jerry returned to the requirements room, the team was shocked to hear the news. "You must be a super negotiator," they said, their eyes sparkling with admiration.

"No," Jerry said, "but I'm a terrific pinball player."

16.6.3 The self-esteem-bad-design cycle

Now we can see one reason the quality of the requirements work depends both on the personality of the requirements team, and on the perceived safety of the working environment. A team with low self-esteem will be afraid to check over-constraints, and consequently will create a more difficult design task. Then because the design task is extra difficult, they won't do as good a job as they might have. As a result, their self-esteem will drop, and they'll be even worse on the next project. Only a skilled intervention from outside can break such a vicious cycle of low self-esteem and bad design.

Postscript
Many of my Women of Power novels capture principles of requirementss gathering in exciting stories as object lessons. Check out The Women of Power.

Even better, buy one of the novels, read it, and if you don't learn something from it, let me know and I'll refund your purchase price along with a bonus book. - Jerry

Methodologies Aren't Enough

This week we continue with sample essays from my various books. The topic this week is taken from the beginning of Exploring Requirements, Volume 1.

Some of our readers would readily agree with the need to resolve the ambiguities in requirements, but they would argue the problem is not with the techniques, but with the technicians. In order to do a better requirements job, they would claim, remove the people from the process and instead use a methodology. Indeed, their preference would be a totally automated methodology, with no people in the development process whatsoever.

When we started teaching software development in 1958, there were few organized development methods. Today, however, packaged methodologies flood the market and almost everyone who develops software has some sort of organized process. For many years, computer-aided software engineering (case) and computer-aided design (cad) dominated the news, both promising to eliminate people from the process. More recently, the Agile movement seems to have rediscovered people, and they are seeing the need for a book about "people-oriented" tools to support their approach. But regardless of the approach, it must ensure everyone gets the right requirements, and gets the requirements right. Won't automated tools do the job without people? We think not, and the story of the Guaranteed Cockroach Killer will tell you why.

1.1 CASE, CAD, and the Cockroach Killer

For many years, a man in New York made a living selling his Guaranteed Cockroach Killer through the classified ads. When you sent your check for five dollars, he cashed it and sent you the kit shown in Figure 1-1.

Figure 1-1. The Guaranteed Cockroach Killer kit. All you have to do is place the roach on block A and then strike it with block B.

The instructions read

1. Place cockroach on block A.

2. Hit cockroach with block B.

If you follow these instructions, you are guaranteed to kill the cockroach. By rights, there should have been a third instruction:

3. Clean up mess. 

Quite likely, nobody ever needed the third instruction—which also meant nobody could collect on the iron-clad guarantee.

Now, what has the Guaranteed Cockroach Killer to do with automated tools? One case document told us case tools are comprised of three basic application development technologies:

1. analysis and design workstations to facilitate the capture of specifications

2. dictionaries to manage and control the specification information

3. generators to transform specifications into code and documentation

In our experience, "analysis and design workstations" resemble block A of the cockroach killer. "Dictionaries" resemble block B. If you can somehow figure out the specifications, the workstations will "capture" them and the dictionaries will "manage" them. Once these two steps are done, the generators will clean up the mess and provide your product.

These automated tools are guaranteed to do their job if you simply do your part. This book is about doing your part: getting the roach on the block, and convincing it to stand still long enough for you to deliver the crushing blow.

Whether it's roaches or requirements, the hard part is catching them and getting them to stand still. Generating the code and cleaning up the squashed roach are messy jobs, but in a different way than the first two steps. That's why we think you'll still need the tools described in this book. Not only that, but the better your automated tools, the more you'll need our people-oriented tools. You can see why in the book sample at Smashwords.

Excessive Realism in Teaching Simulations

Continuing My Weekly Series of Book Excerpts

(from Experiential Learning: Simulation)

A simulation doesn’t have to be “real” to be successful as an experiential learning tool. What has to be real are the feelings it stimulates in the participants, for feelings are what drive learning. Indeed, too much realism can be harmful to the goal of learning. If the simulation is too close to the participants’ real situation, they be unable to be objective about what they did and what resulted from what they did.

The following sections offer some other effects you may experience if your simulation hits too close to home.

Too accurate detail
Scaling difficulties aren’t the only reason, but they’re a more than adequate reason, why we don’t attempt to do direct simulations to obtain meaningful measurements. We’re not looking for numbers. It’s not answers we seek, but insights. Consequently, when you design a direct simulation, don’t waste your time trying to find “exact” information about the factors in the simulation.

There are other reasons, as well, for not attempting to use a more realistic project. It’s possible to do that, and we have done it often for software projects. Usually, though, it takes more time than people are willing to devote to “a class,” but even more important, it usually generates far more data than we can analyze effectively in hours or even days. But we have done such simulations, for example, in a semester-long college class in software development. Teams in such classes have developed useful software tools that became successful commercial products. One team even developed a hardware computer that executed a high-level language as its machine language.

Too embarrassing
When teaching within a real organization, there may be a much stronger reason to avoid too much accuracy in a direct simulation. If the simulation reveals something embarrassing, anyone who might look bad will try to discredit the entire learning cycle.

A case in point: We were engaged to conduct a week-long workshop for a university’s IT department, to help them improve the quality and timeliness of their in-house-developed software. On Tuesday, we conducted a four-hour simulation of their development process. One of the inventions showed the bad effects of management’s unwillingness to follow some simple suggestions by the testing team.

Both sides–the testers and the developers–were excited to learn how these management actions, or inactions, affected quality and schedules. The participants were so excited, we were sure the final three days of the workshop would result in significant productive changes in the way they developed software. But nothing ever happened.

On Wednesday morning, half the students–the development team–simply didn’t show up. When we investigated, we learned that the development manager had forbidden his employees to attend the remainder of the class. When we confronted him about his decision, he said, “It’s dangerous to let developers and testers get to know one another. If they become friends, the testers will not want to embarrass the developers by finding their bugs.”

Unnecessary detail
Paradoxically, realism often interferes directly with learning from a simulation. For some years, as part of our consulting, we used a simulation of a software development project in which the class was to organize and produce an actual software tool. We were hoping the participants would discover many project pitfalls–information they could apply directly on their jobs.

To add realism to the project, we added a number of the pitfalls we were hoping they would learn to recognize and perhaps avoid. For instance, one of the learning leaders acted as the top executive above their project, and every fifteen minutes or so, he would call a “progress meeting.” We were hoping they would learn to appreciate how much such frequent meetings could disrupt a project. We were pleased to see how well these meetings actually disrupted their project.
But after a few classes, we began to see a pattern in the invention phase. Yes, the participants recognized how much frequent status meetings disrupted the project, but they said, “If management didn’t keep interrupting us to check on progress, we would have done fine. You prevented us from succeeding.”

In other words, they were saying, “We don’t have to learn something or change our behavior. We need our management to change.” If the class involved their executive management, that might have been a good result, but that was not the result we were seeking.

We decided to remove that detail from the simulation. The learning leader who played the role of executive management called no meetings at all. But guess what? The project was still messed up– late and out of control. In the invention phase, they said, “If management didn’t keep interrupting us to check on progress, we would have done fine.”

But this time, they couldn’t blame their learning leaders. It was their own teammates who kept checking status, so now they had to look inward to discover what it was about status meetings that needed to change. By not trying to insert so much detail in the simulation, we allowed the pitfalls to arise from the participants’ own behavior–behavior they could actually do something about.

In realistic simulations, less is more. It’s more because it’s more realistic to let their failures (or successes) arise from their own behaviors, not from intervention by the learning leaders. Once we learned this principle, we began pruning our simulations to the lowest level of leader participation. For instance, they argued that they would have been more successful without specification changes we were introducing randomly. Such changes are a familiar obstacle to anyone who has ever developed software, but again, by adding this detail, we simply gave them another excuse–another way to avoid responsibility for their own unproductive behavior. When we stopped introducing such spec changes, their own developers keep thinking of “nifty features” to introduce into their own product.

Almost but not quite
But realism isn’t the only problem with detail. Just providing detail itself may mess up the learning value of a simulation. The more details you supply, the more it seems to invite the participants to blame slight flaws in some detail you do supply. It’s as if the participants say, “It all seemed so real that we were thrown off course when this detail (pick one) wasn’t quite right.

Even if that detail was essentially unrelated to the learning goals of the simulation, it seems to provide an excuse for failure–and this an excuse for not learning. 

Tinkering With Toys

Continuing our weekly series of excerpts from Jerry's books, today's post is taken from the Experiential Learning series, book 2, Inventing.

Tinkering with Toys is an exercise we designed to explore the relationships among design criteria, documentation difficulty, and system maintenance. It involves one team building and then documenting a device from Tinkertoys, then passing that documentation to another team that must rebuild the device. To give you an idea of the richness of the exercise, which is described in the book, we'll instead list some of the lessons participants have learned.

Each outcome is different, but over the years certain lessons emerge as common to many of the experiences with this exercise. But some of these lessons are important observations about experiential learning in general, so we’ll start the chapter with the first handful, saving the exercise-specific lessons for the end.

Can learning be fun?
Learning from structured experiences can be great fun–and that’s a problem. Many people believe learning and fun are incompatible. They believe that to learn, you must suffer. Looking at an experiential session with that attitude, you are quite likely to believe that people are wasting time, and learning is not happening.

What follows are four essential lessons people need to learn if they’re to overcome the anti-fun myth, and so can be successful participants in some sort of experiential learning session.

Just because you’re having fun doesn’t mean you aren’t learning.
Someone coming in from outside and seeing you at work with your Tinkertoys might not appreciate that you are, in fact, doing something useful. We tend, in our society, to distinguish between “work” and “play”. Part of this tendency is a kind of envy or nostalgia on the part of managers, who are no longer allowed the style of “play” we call “technical work”. (Of course, managers “play” in executive lunches and other activities which some technical people cannot recognize as useful work).

Just because you’re learning doesn’t mean you feel right about having fun.
Most of us have so internalized the work-play dichotomy that when we’re having fun, we look around to see if someone is watching. And, even if nobody is watching, we feel guilty, somehow, about what we’re doing. If only there were some way to measure what we’re accomplishing, we could free ourselves from these guilt feelings, but many of us oppose being measured, too. (And with good reason, if the measurements are not soundly based).

Just because you’re not having fun doesn’t mean you’re not learning.
When the fun is over in the first part of the Tinkertoy exercise and someone has to “pay” for it by documenting the creative mess, a lot of people think that’s the “lesson.” They’ve seen the “point” of the exercise, so why go on to the bitter end? Well, our exercises–unlike schools but much like “life”–don’t have one single “point.” There’s much to be learned in working through to the “bitter end.” For instance, sometimes we have to learn that the apparent end isn’t the end at all.

Just because you’re having fun or not having fun doesn’t mean you are learning anything.
More than anything else, what you learn from experiences depends upon the attitude with which you approach them. In some situations, we just keep repeating our old behaviors, even though they weren’t very successful in the past. In other situations, we repeat our old behavior because it was fun, not really caring if it was accomplishing anything. That view, at least, has some inner logic: you may not get the job done, but you have a good time.

The other way round has no logic at all. If you find yourself having a miserable time, then turn on your learning faculties full blast so you will learn to avoid the situation in the future. 

Zero-Level Design for Experiential Exercises

NOTE: This week, I continue my practice of weekly excerpts from my various books. This week, the excerpt is from the beginning of Volume 1 of the Experiential Learning series.

If you’ve never designed experiential exercises–and possibly even if you have–getting started may seem quite formidable. Over the years, we’ve found that the concept of zero-level design gets us over these start-up willies, so we’re offering it as our first tip.

A zero-level design is the simplest design that will satisfy the principal learning goals.

The idea behind the zero-level design is to relieve, as quickly as possible, the anxiety of designing exercises.
Once you have a zero-level design in hand, you know you can do at least a minimal job as learning leader, so you can relax and feel free to be creative about coming up with something better. You know that if you fail to come up with a better exercise, you still won’t fail in your class, because you do have an adequate exercise in hand.

1.1 A Zero-Level Example

For instance, as part of a process improvement program, we were asked to teach how observation could be helpful. We hadn’t done such an exercise before, but we needed to say whether we would do it or not. Here’s a zero-level design we cooked up ten seconds after we were given this goal, a design that allowed us to accept the assignment on the spot:

      1. Divide the class into two groups. (In a large class, use an even number of groups.)

2. Designate the groups as A and B. We don’t tell the groups, but A will be performing a simple process without the help of observers, while B will be performing the same process with observers. A is the control group.
   
   
3. Privately tell the B groups to chose one of their members to observe their process.
   
   
4. Give each group a deck of shuffled playing cards. (For large groups, use multiple decks.)
   
   
5. Tell them their goal is to sort the cards into a specified order as fast as possible,
   but with 5 second penalties for each card out of order.
   
   
6. Time each group as they sort the cards. When they are all finished, have each group check another group’s deck for cards out of order. Apply penalties and post the net times.
   
   
7. Now have each group meet and discuss how they can improve. The B group, of course, has a designated observer who can provide information as seen from the outside.
   
   
8. Shuffle the cards and have each group sort again. Measure and post the times as before.
   
   
9. Using their experiences, invent principles of how observation can help or hinder process improvement.
   

Now this is a very simple exercise, but it will get people talking about process improvement. With this in your back pocket, you can relax and begin thinking of better things. For example, you might make adjustments to tune this exercise–give the observers a checklist to guide their observations; practice on sample groups to decide the best group size and number of decks; modify the exercise for a large class so you have groups of different sizes.

But even more important, you can put this zero-level design aside and come up with something completely different. That’s the big advantage to a quick, zero-level design. At the very least, it will keep you from slipping back into reading slides full of bullet-points to a sleeping classroom. 

A Conventional but Flawed View of Leadership

Contuining my excerpts from various books, this week I'm posting this segment from Becoming a Technical Leader.

Psychologists and management theorists have dozens of models of leadership, with a typical one of their texts offering this explanation:

There are two principal ways to identify the leaders of a group:

1. asking the members to identify which members they regard as most influential in directing the group, or

2. asking observers to name the most influential members, or to record the frequency of effective influencing actions.

Although they appear to be scientific, these models are based on the opinions of the members or the observers, and on their ability to observe "effective influencing actions." Over the years, I began to see some flaws in that approach.

For instance, a company recently retained me to help a group of computer programmers improve their problem-solving techniques. The company was losing thousands of dollars of sales each passing day because of a subtle error in its software product. Until the programmers could find the error, the product was useless. To help the group, I videotaped them as they struggled to find the error.

In one hour of observation, the "effective influencing actions" of the four programmers involved looked like this:

Arnie 112 actions

Phyllis 52 actions

Weber 23 actions

Martha 0 actions

Martha's actions were easy to record. She sat like a zombie through the entire hour, studying the printout of the erroneous program. She said nothing, made no gestures, and didn't even smile or frown. Without question, she had no influence on the group whatsoever.

After consuming an hour with their effective influencing actions, the other group members were no closer to solving the problem than when they started. All of a sudden, Martha lifted her eyes from the listing, pointed a finger at one line, and said, ever so quietly, "This word should be '87AB0023', not '87AB0022'." Then Arnie, Phyllis, and Weber resumed their agitated discussion. They terminated the meeting ten minutes later, after they had convinced themselves that Martha was indeed correct.

When I asked the group who had been their most influential member, they all said, "Arnie." Then I played the videotape, asking them to be especially alert to the method by which their problem was solved. After watching the tape, Arnie, Phyllis, and Weber changed their answer to "Martha." Why? Because in terms of solving their problem, the table of effective influencing actions should have read

Arnie 0 actions

Phyllis 0 actions

Weber 0 actions

Martha 1 action

Without Martha's contribution, the meeting would have gone nowhere, yet non-programming psychologists would have probably missed Martha's role entirely. When such nontechnical psychologists observe our workshops, they are consistently befuddled by the dynamics of the teams as they solve technical problems. It's as if the psychologists were watching people from another planet, people whose culture and language look and sound superficially like ours but are entirely different.

NOTE: Up until now, I haven't been much of a faithful blogger. I keep telling myself it's because I'm too busy writing other things and trying to induce people to buy them—or at least read them for free. At long last, however, I applied some of my own problem-solving advice and solved two problems by putting them together.

At least I'm going to try. Each week, instead of writing a new blog post, I'm going to snatch a bit of writing from one of my books, something that holds together on its own and is worth reading. Perhaps it will also convince a reader or two to read the whole book, but it any case, I will try to make each piece worth their time.

This week, I'm starting the experiment with that strategy. Now I have another problem. With about a hundred published books, how will I choose which book to use each week. I don't know how I'll solve that problem in general, but just so I don't have to think about it today, I'm starting in alphabetical order. So, this week's snippet is taken from a book I wrote with Don Gause, Are Your Lights On? At the very least, read it to learn where the title came from.

Chapter 13. The lights at the end of the tunnel.

A long auto tunnel through the mountains above Lake Geneva has just been completed. Just before the opening, the chief engineer remembers she has forgotten to warn motorists to turn on their lights before entering the tunnel. Even though the tunnel is well illuminated, the motorists must be prepared to prevent a catastrophe in the event of a power failure—a plausible eventuality in the mountains.

A sign is made saying:

WARNING: TUNNEL AHEAD

PLEASE TURN YOUR HEADLIGHTS ON.

The tunnel, with the sign well ahead of the entrance, is opened on schedule, and everyone relaxes, now that the problem is solved.

About 400 meters past the Eastern end of the tunnel stands the world's most scenic rest stop, with a sweeping view from high above the lake. Hundreds of tourists stop there each day to enjoy the view, perform important bodily functions, and perhaps partake of a small but tasty piquenique.

And every day, ten or more of those hundreds return to their cars, refreshed in body and soul, only to find a dead battery from having left their lights on! The gendarmes are tying up most of their resources getting them started or hauling them away. Tourists are complaining and swearing to tell their friends not to visit Switzerland.

As usual, we ask you to pause and ask yourself:

WHOSE PROBLEM IS IT?

(a) the drivers

(b) the passengers (if any)

(c) the chief engineer

(d) the gendarmes

(e) the president of the canton

(f) the automobile clubs

(g) none of the above

(h) all of the above

The strong tendency in this type of problem—with an explicit "designer" or "engineer"—is to consider it her problem. Not only do the drivers in this case consider it the engineer's problem, but the engineer probably does too. It's a common impression among architects, engineers, and other designers that they must take care of everything.

In this instance, the engineer considered various solutions she could impose upon the drivers and their passengers.

(1) She could put a sign at the end of the tunnel saying, TURN OFF YOUR LIGHTS but then people would turn off their lights at night...

(2) She could ignore the situation and let people...No, that was already happening, and the government officials think the engineer has done a lousy job.

(3) She could put a battery-charging station at the scenic overlook. But that would be expensive to maintain, and would make people even more furious if it didn't work.

(4) She could give the recharging station franchise to a private firm. But that would commercialize the overlook and be unacceptable to the government and the tourists.

(5) She could put a more explicit sign at the end of the tunnel.

The engineer felt intuitively there should be some way to write a more explicit sign. She worked on several alternatives and eventually came up with a masterpiece of Swiss precision:

IF IT IS DAYLIGHT, AND IF YOUR LIGHTS ARE ON, TURN OFF YOUR LIGHTS;

IF IT IS DARK, AND IF YOUR LIGHTS ARE OFF, TURN YOUR LIGHTS ON;

IF IT IS DAYLIGHT, AND IF YOUR LIGHTS ARE OFF, LEAVE YOUR LIGHTS OFF;

IF IT IS DARK, AND IF YOUR LIGHTS ARE ON, LEAVE YOUR LIGHTS ON.

By the time anybody had finished reading this sign (in three languages), his car would be over the guardrail and gurgling to the bottom of the lake, which would not be an acceptable solution at all. Besides, what about funerals? There must be a better way!

Instead of all this complication, the chief engineer took the approach of "It's THEIR problem"—but it was her problem to assist them. She assumed the drivers had a strong motivation to solve the problem, but they might need a little reminding. She also assumed the drivers—if they were to be: licensed at all—couldn't be complete dummies. All they needed was a sign at the end of the tunnel:

ARE YOUR LIGHTS ON?

If they weren't smart enough to deal with that, dead batteries were the least of their problems.

This sign eliminated the problem, and the message was short enough to be put on the sign in several languages. The engineer always remembered her lesson from this situation:

IF PEOPLE REALLY HAVE THEIR LIGHTS ON,

A LITTLE REMINDER MAY BE MORE EFFECTIVE

THAN YOUR COMPLICATED SOLUTION.

Are your lights on?

Q and A from China

I was recently asked by my Chinese translator to answer a series of questions for some Chinese students and fans. Here are the questions and my top-of-the-head answers for your enjoymentL

1. You have written many technical books in your early years, but now the books you wrote mostly are about human. What is the cause of this transition?

In the early days of computing, we were burdened with so many technical problems that we couldn't afford to think of much else. When I started, in the 1950s, there were probably fewer that 100 people in the United States who could write a serious program. I personally could have exclusive access to one computer (the IBM 704 #1) that had about 10% of the computing problem in the entire world. Today, a typical person carries a thousand times that much computing power in his or her pocket telephone.

In that environment, we desperately needed more people who could program anything, and anything they could program, no matter how poorly designed, was greatly appreciated. Today, however, there must be more than a million people in the United States who write programs every day. (I don't know how many in China, but I'm sure it's even more.)

Back then, our failures all seemed to be programming problems, technical errors in code. So, that's what I wrote about. As time went by, we had more programmers, more and bigger projects, and though the technical problems remained, we could usually find a large number of people who can solve them. But, with bigger and more complex projects, we began to see that human failures were increasingly frequent, and more serious. At the same time, none of us technically trained people had much training or instinct for solving those human problems. So, because I've always tried to write about solutions to the problems we weren't solving, I gradually changed my main focus–though of course I still write about technical problems, too.

2. How to embrace the great ideas in your book? Sometimes though readers appreciated the idea, still they find them too hard to implement.

If problems are easy to solve, we solve them. After we've done that for a while, what we have left are the more difficult problems, so naturally we have more difficulty solving them. But, if they are important problems, it's worth the hard work it takes to learn to solve them.

One thing my readers can depend upon, though, is that every idea I describe in my books is an idea that some other people have used to solve their problems. So, if you are having trouble implementing one of those ideas, support your work by remembering that someone has really done this successfully before you.

Sometimes, though, the reason you have difficulty is that you believe you must solve every problem alone, with no help from anyone else. In the United States, I know that our schools contribute to this attitude–because receiving help in solving a problem is called "cheating." That might be okay in some school situations, but in the world of real work, the people who succeed best are those people who know how to work with others. So, next time you have difficulty implementing an idea that you feel is important, seek and find another person or persons to work with you.

Some of my readers have told me that they use a "virtual Jerry" approach to get the help they need. When they're stuck, or slow, they ask themselves, "How would Jerry approach this difficulty?" A few actually keep a picture of me in their office, so they can talk the problem over with their "virtual Jerry."

I know it sounds silly, but they say it works. I believe them, too, because I use a similar approach with virtual versions of some of my teachers–Virginia Satir, Kenneth Boulding, Ross Ashby, Anatol Rapoport, Bernie Dimsdale, to name a few. (Actually, I learned this virtual technique from Bernie Dimsdale, who used it with his teacher, the great John von Neumann.)

3. When is the right time to go to the consulting firm?

Does this mean when is the right time to seek the help of a consulting firm? Assuming that's what it means, the answer, of course, is "it depends."

But what does it depend on? Perhaps it's easier to talk about when is the right time NOT to seek the help of a consulting firm. If you eliminate those wrong times, your chances of success will be greatly improved. So here are a few tips:

a. Don't seek a consultant when you're really trying to find someone to take the blame for your own failure. You must really want to solve the problem you're describing–NOT just so you can say to your boss, "If this expensive consultant couldn't solve the problem, you can't blame us for not solving it."

b. Don't seek a consultant if that consultant's success will make you look like a failure. For example, if your boss thinks that anybody who needs help is a bad employee, do NOT seek a consultant. Instead, seek a new boss.

c. Do NOT seek the cheapest consultant, but do NOT seek the most expensive one, either. Seek a consultant for whom you can get personal recommendations from people who have actually used that consultant. Just be sure that the advice you seek will, if successful, be worth what you have to pay the consultant.

d. Do NOT seek a consultant if you're not ready to be told that you've actually been working on the wrong problem. About half the time I'm hired as a consultant, my most important advice is showing them a different definition of their problem.

Well, that's enough of an answer to this question, though there are many other reasons for not hiring a consultant. Maybe you need to hire a consultant to tell you whether or not you should hire a consultant.

4. There are many consulting firms in the market, and they all have their own strength. How does a company choose the right consulting firm for them?

This is a good example of what I was talking about in the previous question (3)–problem definition.

Your problem is NOT how to choose the right consulting FIRM. Your problem may be how to choose the right CONSULTANT. Consulting firms typically want you to believe that any consultant they send to you is as good as any other in their employ. That is simply not true. It is never true, unless the firm has only one employee.

My own firm has just two consultants–me and Dani, my wife and partner. We are not equal, not the same. For some consulting jobs, I'm the best one for you. For other jobs, she's the best, far better than me. So, you would do wrong to choose our FIRM. Instead, you should choose one of us or the other–or some other consultant entirely.

As far as how to choose that consultant, there's no short answer, but you can read my two books on consulting to learn much more about how to make such a choice.

5. Sometimes, the discontentment towards consulting firms and their solutions only come up during the consulting process, how to avoid this situation?

First, read my answers to question (4). Don't take anyone you haven't chosen–such as when a firm tells you they have to substitute another one of their people for the consultant you've chosen.

Second, realize from the start, and keep realizing, that you can "fire" a consultant at any time you're not satisfied. If you keep that in mind, you'll be more careful when choosing in the first place because you won't be able to blame a failure on anybody but yourself. "If this consultant wasn't good enough, why did you choose him or her?"

In my own business, I have always offered my customers a money-back guarantee. If they are not satisfied with my work for them, the simply need to ask and I will return any or all of what they have paid me. Because I know that, I'm always checking with my customers whether or not they are satisfied with my work. If they are not, we either fix the situation right them, or terminate the relationship right then.

That way, my customers are never surprised to find themselves deeply discontented with the consultant's work. Fundamentally, we are using the principle of addressing problems before they grow too big to solve. At least my clients can never say, "We're not satisfied with his work, but we've spent all our consulting money and don't have enough left to hire someone else.

6. Does psychology play a major role in consultancy? How important is that?

If I had to give a number, I'd say that psychology is about 90% of the consulting job. There's no point giving advice if it's not understood, nor if it's not going to be followed. That's why psychology is such a large element of the consulting role.

7. It is possible that one solution works in one country and fails to succeed in another country. Is culture an important factor in the success of consultancy?

It's not only possible. It happens all the time. That's why my one partner, Dani, is a professional anthropologist. Before she retired from general consulting to work with animal behavior consulting, perhaps half of our assignments were in situations where other consultants had failed because they did not take cultural differences into account.

8. How to find out the real problem behind the superficial?

Again, there's no short answer, but there is a short book that Don Gause and I wrote: Are Your Lights On? or How to Know What the Problem Really Is.

To give you some kind of answer here, I'd say that the most important thing to know about problem definition is this: Most of the time when people repeatedly fail to solve a problem, the reason they fail is that they have the wrong problem definition. So, before plunging into solving, spend some time questioning and refining the definition you've been using.

Perhaps you will be surprised at this, but in most of my consulting assignments, my clients actually know already what the problem is, and even how to solve it. But they don't know they know, or don't like to admit what the problem is. So, if you listen carefully and respectfully, you can usually find out what you need to know from them.

9. It is awesome to save a dying company, but sometimes the company dies no matter what you do. How to evaluate your work? How do you know when to take credits?

First of all, sometimes letting the company die–even helping it to die–is the right thing to do. In that case, keeping it alive means you've failed as a consultant.

In other cases, the company could be saved, but the key people are simply not willing to do what is necessary to save it. For instance, in one assignment, our client was failing because they could never deliver a quality product. They reason for that all could be traced back to one of the founders, who was an abusive alcoholic whose behavior managed to drive out all their best technical people. We demonstrated his destructive role, but he refused to leave the company. (He was  half-owner, but would not even accept an offer to buy his half and leave.) They company failed. Many of the employees then formed a new company, a start-up that succeeded marvelously (without the abusive alcoholic).

10. I believe a great consultant does not only know knowledge of his own domain, but also know much about politics, economy, psychology, society, culture etc. How do you manage to do that?

The question implies that I am a great consultant, and if so, that I know how I got that way. I'm not sure either of those implications is correct, but I can say that I do value my knowledge of many, many fields that others do not think have anything much to do with consulting in the information processing industry.

I have a rule I've always followed–two rules, actually–that may be part of the answer to your question:

a. Sometimes I find myself thinking "subject X has absolutely nothing to do with my consulting. Instead of concluding that "therefore, I don't have to learn anything about subject X," I conclude that "I obviously don't know enough about subject X, because everything connects with everything else."

b. Whenever I decide that I don't know anything about a subject, I set myself the high-priority task of learning about that subject. In my younger years, I would then try to take a course in the subject. Later, I found that I could learn faster and more deeply by reading one or more of the best books in that subject.

Even later, I learned that the very best way for me to learn about something I knew nothing about was to write a book about it. I told myself, "If I write something ignorant or stupid about this subject, then I'll make a fool of myself for all to see. Therefore, I'd better study deep and hard to prepare myself to write the book."

I don't always actually write the book, but I always prepare as if I'm going to write it. That fear of writing a dumb book motivates my learning more than anything else could do. (If I actually wrote all the books I've prepared for, I would have written about a thousand books, rather than the hundred or so that I've actually written so far.)

11. Are there any advices for young consultant or the ones who are interested in this career?

I wrote my book, The Secrets of Consulting, in response to hearning this same question three times in one day from young students of mine. So, of course I think that reading that book and its sequel, More Secrets of Consulting, would be a good starting point.

Then, for me, an important reason for my success is my number one criterion for accepting a certain job and/or remaining on a job: "Am satisfied with what I'm learning on this job, and also with the rate of that learning?" If you follow that criterion throughout your career, you have a good chance of being a good consultant. Never stay where you're not learning. That's the most important advice I could give.

- Jerry Weinberg  17 January 2014

My Christmas Poem

Twas the week before Christmas,

And all through the house,

Every creature was fretting

And starting to grouse.

Then from UPS

Came a gift flowerpot

From a friendly old colleague

Whose gift I'd forgot.  

But then I remembered:

Don't feel like a schnook

In just a few minutes

I can send a fine book

No wrapping, no breakage,

No address to scrawl,

No trade-ins, no trouble,

'Cause one size fits all.

So boot up your browser,

And don't be a schnook.

In a fistful of keystrokes

You can send an e-book.

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

For just $4.99, you can go to http://www.geraldmweinberg.com/Site/Novels.html and send your friend an engaging, exciting story, one that also carries one or more science/technology themes. 

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

The Residue Class Mysteries Themes

The Freshman Murders: Computers, Culture, Genealogy

Where There's a Will There's a Murder: Mathematics, Anthropology

The Stringers Series Themes

 First Stringers: Physics, Social Psychology

 Second Stringers: Space Travel, Psychology

The Women of Power Series Themes

Mistress of Molecules: Chemistry, Politics

The Hands of God: Parallel Computing, Neurophysiology, and Prosthetics

Earth’s Endless Effort: Unconventional Computers, Alien Contact

The Aremac Project Series Themes

The Aremac: Software Development, Testing, Security

Aremac Power: Risks and  Rewards of Invention

And, of course, always Computers!

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

To see the covers of most of my books, look at 

http://www.pinterest.com/geraldweinberg/fun-practical-things-to-read/

Satir Outstanding Service Award

Of all the work that I do, in my opinion, the most important is bringing Virginia Satir's teachings to the people of the world. For that reason, I'm especially proud of the award I received from the Satir Organization yesterday. Here's what the award looks like. First, the certificate:

And here's the trophy:

Thanks to all the people who contributed to this work.

Who Owns the Zebra?

I collect problem-solving methods. A recent letter from a follower give me the chance to show you another method I often use on the problems that bother me most. It's especially helpful with problems I'm having with other people. Here's the letter and my response:

Who Owns the Zebra? It was the first difficult logic puzzle I solved. I saw it in a Reader’s Digest once when I was waiting for a haircut at a barber shop. And of course it was back when cigarettes were considered cool (but not Kool, what my parents smoked – yuck!). I was around 8 years old at them time.

http://people.sc.fsu.edu/~jburkardt/fun/puzzles/zebra_puzzle.html

For your convenience, here's the puzzle from this website:

---

On a city block there are five houses in a row, numbered from left to right, each of a different color and inhabited by men of different nationalities, with different pets, drinks and cigarettes. You are given the following clues:

• The Englishman lives in the red house;
• The Spaniard owns the dog;
• Coffee is drunk in the green house;
• The Ukrainian drinks tea;
• The green house is immediately to the right of the ivory house;
• The Old Gold smoker owns snails;
• Kools are smoked in the yellow house;
• Milk is drunk in house #3;
• The Norwegian lives in house #1;
• The man who smokes Chesterfields lives in the house next to the man with the fox;
• Kools are smoked in the house next to the house where the horse is kept;
• The Lucky Strike smoker drinks orange juice;
• The Japanese smokes Parliaments;
• The Norwegian lives next to the blue house;

Now, who drinks water? And who owns the zebra?
I remember reading this puzzle in the International Edition of Life Magazine, back in 1962.
If you'd like to see an interactive Windows program that can generate thousands of puzzles like this, take a look at Everett Kaser's SHERLOCK program.
I give up, show me the solution.

---

Since most of the people in the puzzle were smokers in 1962, the zebra puzzle is now easy to solve, using one of my favorite methods--the 50-year approach:

1. Put the puzzle in an envelope. Write on the envelope: "Do not open until [50 years from today]."

2. When the 50 years have passed, open the envelope. Chances are that it will no longer be a problem.

3. If, however, it's still a problem, get another envelope and repeat step 1. 

4. By the time you open envelope #2, the problem will be solved for you. It will no longer be a problem. I guarantee it.

http://www.geraldmweinberg.com/Site/AYLO.html