Sunday, April 13, 2014

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:
pastedGraphic_1.png
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?

Friday, January 17, 2014

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

Wednesday, December 11, 2013

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 

Thursday, November 14, 2013

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.

Wednesday, September 04, 2013

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.


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

Monday, May 27, 2013

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


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.

Tuesday, May 14, 2013

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.