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

Modeling Programmer Productivity

Continuing where I left off in my previous blog, you may recall that we were discussing the value or otherwise of programming experience in terms of productivity. I had suggested there was an important truth to be learned from the study of productivity models.

"There is a perception in some tech circles that older programmers aren’t able to keep pace with rapidly changing technology, and that they are discriminated against in the software field. But a new study from North Carolina State University indicates that the knowledge and skills of programmers actually improve over time—and that older programmers know as much (or more) than their younger peers when it comes to recent software platforms."

http://www.rdmag.com/news/2013/04/older-wiser-study-shows-software-developers-skills-improve-over-time

This study didn't surprise me. Nor did it surprise many of my programmer friends. Why, then, do so many managers still believe that older programmers are less skilled than their younger co-workers?

The answer lies in fallacious reasoning. Let's see how that works. Pretend we were able to follow the careers of 100 programmer trainees who started together six years ago. Each year, some of them will drop out of programming because they don't like it or can't do it very well.

These dropouts will be high at the beginning, then decline as salaries rise to overcome any residual dislike.

After a year or two, some of the better performers will be offered "promotions" outside of programming. Some will accept. Some will decline, preferring the work they know and do well.

Generally, though, the promotion will be offered principally to those who are the better programmers—whether or not they would be the most qualified to be analysts, managers, database administrators, or what have you.

The following table shows how the allocation of these 100 trainees changes over a six-year period.

The figures are not meant to be exact, but only suggestive of trends.

Now suppose we break down this table into two tables, each starting with 50 of the trainees. First, we have the "least able" 50:

Now consider the most able"50:

In other words, according to this model, after six years, as a result of personnel practices, about 77 percent of the programmers come from the lowest 50 per cent in original ability. The very worst have mostly dropped out early, but not enough to counteract the loss of the better ones.

Most of those better ones have been promoted out to to meet rapidly growing demands for experienced personnel in non-programming jobs. This loss is the result of two fallacious management beliefs:

1. The best programmers will make the best managers, team leaders, etc.

2. There's no point keeping older programmers in the trade because the younger ones are better.

Misled by these two mistaken beliefs, managers keep promoting out their most experienced programmers (except for those few who refuse the promotions).

As an experiment, you might try substituting your own company's personnel policies into this model to create your own tables.

You may find, as many have, that what they are measuring, when they measure "years of experience", is actually combination of "years passed over for promotion" and "years refused to take a promotion.

There's much more to the complex subject of experience, but these simple models are food for thought. Perhaps you'll have them in mind next time you're interviewing a candidate—or even next time you review your personnel policies.

Software Development: Experience vs. Performance

Experience vs. Performance

"Experience is the best teacher."

"Experience is the only teacher."

"Experience keeps a dear school, but fools will learn in no other."

"Experience doesn't necessarily teach anything."

"Experience is the only school in which the test comes before the lesson."

There may be more folk wisdom on the subject of experience than on the subject of love. After all, if we couldn't appeal to experience, how could we old roosters keep control of the henhouse?

When I was young, I was frustrated by lack of "experience" at every turn. No matter how hard I worked, I could gain no more than one year's experience each year. At 19, a year is a lot longer than at year 79.

"Experience" is also proving frustrating to many programming managers, whatever their ages.

"What is the value," I'm often asked, "of one year of programming experience?"

"Does productivity actually increase after the third year of programming experience?" "Don't programmers 'burn out' after five years?"

Quite a few programming managers, if they were asked to plot the productivity value of experience, would produce a graph something like that in Figure 1. They've found that after roughly three years, additional years of experience don't seem to add significantly to a programmer's productivity.

 Figure 1.

Managers who hold this model naturally are unwilling to pay a premium for many years of experience. Usually, they will seek programmers on the job market with one or two years of experience.

One problem with this model is that it may fail to consider problem difficulty. In most shops, the more experienced programmers are given, on the average, more difficult programs to write. If the measures of productivity fail to consider problem difficulty, the more experienced programmers will naturally have their productivity underestimated. In some cases, a more realistic model would be that of Figure 2.

Figure 2.

This slightly less pessimistic curve is supported by the results of a number of studies in the psychology of programming. When programmers of varying experience are asked to perform the same task—coding, finding bugs, developing test data—the average performance versus experience curve frequently looks like that of Figure 2.

Even so, a manager studying Figure 2 may still wish to follow the strategy of hiring programmers with very little experience—in order to take advantage of the steeply rising segment of the curve.

Managers in smaller companies, however, may have more discretion. If they are perceptive, they can profit by noting the difference between each individual programmer and the presumed average.

The same studies of programming support the view that a manager does well by appraising the quality of each candidate's experience. Does the programmer really have "10 years of experience," or is it more accurately characterized as "one year of experience, 10 times?"

If we divide the programmers in each study into two groups—high performance and low performance—we generally find that the experience curves look like Figure 3.

Figure 3.

The curve we see in Figure 1 or Figure 2 is, probably, a mixing of these two curves into a single curve.

Conversely, programmers often tolerate low-paying jobs their first year or two, in order to be in a company that pays well for longevity, rather than for actual output.

Both Figure 1 and Figure 2 represent models of the average programmer in really large companies, employing hundreds or thousands of programmers, personnel policies may force them to follow the averages in hiring and setting wages.

Do these two curves represent anything real, or are they artificial manipulations of data? My own experience with,such studies and on the job tells me that there is an important truth here. In my next blog entry, I'll examine this truth and why so many managers fail to understand it.

Pricing for Non-Profit Organizations

A recent tweet by Harry Tucker raised the question:

Should you work for free?

to which I replied:

No money is okay, as for charity, but they must always pay in some form or they won't value it.

I wrote extensively about pricing in The Secrets of Consulting, much more than I could express in 140 characters. But for those who don't wish to read an entire book, I offer the following essay on the narrow topic of pricing for non-profit organizations:

The First Law of Pricing says:

Pricing has many functions, only one of which is the exchange of money

In addition, The Second Law of Pricing states,

The more they pay you, the more they love you.

The less they pay you, the less they respect you.

If you work with organizations with no possibility of meeting your usual fee scale. You can still help the client respect you by setting the proper price. All you need to remember is The Third Law of Pricing:

The money is usually the smallest part of the price.

There are many costs besides money: the psychological cost of admitting there is a problem; the labor to get approval for your visit; the difficulty of changing schedules; the time and trouble to line up people to see you; plus all the extra work the client must do after you've gone.

By arranging for clients to pay something of value to them, even if it's not paid to you, you have, in effect, raised the price. If they've invested something in bringing you there, they're more likely to listen to you once you arrive. But beware. Even though not much money changes hands you may inadvertently raise the price beyond what the clients are willing to pay.

Knowing that price is more than money, you can increase your compensation in a variety of ways that may not increase the cost to your client. I can sometimes use services such as arranged contacts with prospective clients in the area, computing services, or the use 

of a library.

I often receive free travel to a place I've always wanted to visit. I frequently ask clients to take me sightseeing around their area. Universities are particularly good at this. 

Properly planned, a university visit can be rewarding professionally, far in excess of any fee. Without a plan, you'll just be used, wrung dry of whatever knowledge you have, treated with disrespect or ignored, and then cast aside to find your own way back to the airport.

For me, consulting is a paid education. By arranging visits with brilliant people, I receive the best an organization has to offer, without extra cost to my client—which illustrates The Fourth Law of Pricing:

Pricing is not a zero-sum game.

In short, your gains don't have to be their losses.

* * *

Bio: Gerald Weinberg is author of more than 100 books, including the best-selling The Secrets of Consulting series. He is a principal in the international consulting firm of Weinberg and Weinberg, whose non-profit clients include state and national governments; churches; universities; medical centers; voluntary organizations; and the Library of Congress. The festschrift, The Gift of Time (Fiona Charles, ed.) honors his work for his 75th birthday. His website: http://www.geraldmweinberg.com

Meet the Seashores

Roger Ebert, the film critic, died today. I don't know what I can do to replace him in my life, because  for the past 30+ years, he was the one I went to when I didn't know which movie to watch (or not watch).

I will need to replace Roger with another film critic, but I don't know how to replace him because Charlie Seashore died last month, followed a few days later by Edie Seashore. For the past 30+ years, Charlie and Edie were the ones I went to when I didn't know what to do about anything in my life, especially things more important than movies.

Edie and Charlie and I were connected in a plethora of ways. Though we lived thousands of miles apart, we visited each other often. Aside from these personal friendships, we frequently were consultants to each other. I assisted in some of their workshops; they assisted in some of mine. These interactions were always of high intensity and deep learnings, but perhaps the most intense, the most educational, were working on our feedback book, What Did You Say?.

With the perspective of several decades, I'd have to admit that the book was a success. Though we spent not a penny on promotion, What Did You Say? became a word-of-mouth classic, selling tens of thousands of copies and changing a similar number of lives. We probably would have sold even more, but the book was hard to find in the USA–and virtually impossible to obtain overseas.

In recent years, with the changing technology in publishing, we began talking about, then working on, an electronic (ebook) version of What Did You Say?. We corrected numerous small errors and added two entirely new chapter. The work went slowly because all three of us were immersed in our other work, especially visiting clients and leading workshops. And then they died.

Because Edie and Charlie were two of the world's greatest consultants and trainers, they were always incredibly busy–and that busyness created the one flaw in their work: They seldom had the time to sit down and write about the magical things they were doing with their students and clients. Without a massive collection of written words, only a relatively few of us lucky ones had a chance to share their magic.

In my shock, my first reaction was to drop the entire project, but clients kept asking about how the book was coming along. It took me weeks just to face filing away all our drafts. The filing was so painful and slow, I just knew I could never finish the book without the rest of my team. As I filed, though, I realized that, except for some final polishing and formatting, we had already finished.

I knew then that I had to do that polishing and formatting. The ebook could be the way for thousands of people to come to know Charlie and Edie, if only in a partial way. So, I put almost everything else aside and turned my editorial crank–grinding out what became the Revised Second Edition of What Did You Say?. I invite you to get yourself a copy and get to know the Seashores. (And learn a few things about feedback.)

Special Questions

Note: The following tale is adapted from my book, Rethinking Systems Analysis and Design. What's the moral of this tale? After you make your own suggestions, take a look at the original tale and see what the book has to say.

Harlan Mills predicted that some day programmers will make so few errors that they'll remember every one they ever made in their entire career. I've had a long career and I've made rather more than the one error per year that Harlan predicted. One a day might be more like it. But some errors were so gross or so costly that they stand out among the thousands.

Over forty years ago, I was analyst/programmer for a service bureau studying a job that involved processing a million cards through the IBM 650 computer. Because of limitations on the 650's ability to read cards, the only punches allowed in the cards were alphabetics and numerics. Special characters could not be read at all.

When questioning the client in our very first meeting,I asked, "Are there any spetial characters in the cards?"

"No," he replied, "none whatsoever."

"Good," I said, "but I have to be sure. Are you certain that there are no special characters at all?"

"I'm quite certain. I know the data very well, and there are no special characters."

On that assurance, we went ahead with designing and programming the application, only to discover on our first production run that the system was hanging up on cards like this:

THREADED BOLT—1/2" #7

About sixty-five percent of the cards contained special characters, but when I confronted the client with this figure, he appeared genuinely puzzled, "But there are no special characters," he pleaded.

"Oh, no," I said triumphantly, "then what about this dash, slash, quote, and number .sign?"

Nothing New Ever Works

The best "review" of one of my books is a testimonial about how the book has been useful. Here's a letter from Jon Jagger about how a law from The Secrets of Consulting helped him help his son, Patrick, who was ill.





                      
Hi Jerry,
I just had a moment of enlightenment about the New Law I wanted to share with you...

I was giving Patrick, my son, some calpol (liquid paracetamol - he's ill off school today).
The bottle had a new plastic widget in the top.
With the bottle there was a new small syringe with a new plunger.
This was a new design - instead of simply pouring the calpol onto a teaspoon you clearly had to fill up the syringe.
Try as I might I could not get the syringe through the hole in the plastic widget in the neck of the bottle. 

So was it The New Law - Nothing new ever works? 

My beautiful wife Natalie came to my rescue.
It did work and she showed me how.

I just re-read The New Law from your book.
I noticed that all the examples, the coffee maker, the pills, the car-battery, the car, the hospital procedure were examples where the new thing was genuinely not working. But in my case the new thing WAS working.  It was ME that was not working!

From this I have realized that

1) It's easy to think the emphasis in "Nothing New Ever Works" is on the word "new" but it's equally on the work "works"!

2) Something being new is a relationship

3) Something working is a relationship

4) When I say "it's not working" what I always mean is "I can't get it working"

Also, it might give some insight into the question you pose at the end of the New Law...

"Everyone knows that new things never work."
"Then why is everyone obsessed with changing everything for something new?"
"If you answer that, you'll have something worth writing about"

Well, when things go wrong we can look for the cause outside of ourselves, or we can look for the cause inside of ourselves. 
But, looking for the cause inside of ourselves would mean WE had failed. Which is unthinkable.
Therefore the cause must be outside of ourselves. 
Viz, if it's a choice between changing the world around us, or changing the world inside us, outside wins. 
And that's one reason why we create new things! 

Cheers
Jon