Reasons

©2001 Gerald M. Weinberg, www.geraldmweinberg.com

[Note: In September, 2000, at the SEI's Software Engineering Symposium in Washington D. C., Jerry was the recipient of the 2000 Stevens Award. The award recipient is recognized for outstanding contributions to the literature or practice of methods for software development. In receiving the award, Jerry gave the Stevens Lecture on Software Development Methods, the purpose of which is to advance the state of software development methods and enhance their continuing evolution. The following column is abstracted from part of his Stevens Lecture. ]

I remember one summer day during World War II when my father, Harry, and I were discussing the water restrictions that had been imposed because of drought conditions. I was worried that we might run out of water, and my father said, “Yes, it could happen that we run out of water. Lots of things can run out – water, sugar, meat, gasoline, bread, even air. But there’s one thing that will never run out.”

“What’s that?” I asked, looking for reassurance.

“Reasons,” he said. “People will never run out of reasons.”

Harry was the first change artist I knew. At that time, he was working for Sears, starting up new stores and installing new procedures in existing stores. He often took me on trips, and I got to see him working. I particularly recall the difficulty he had teaching salespeople about Sears’ policy on returned tools and paint.

The policy was simple: The customer was always right, so just replace anything that they didn’t like, no questions asked. If possible, find out what they didn’t like about it, but never, never question their right to a replacement. I’d watched him coach salespeople through a number of these transactions, so I thought I understood what he mean by never running out of reasons. Even though the policy was clear – replacement with no questions asked – the customers always had elaborate stories of why the item wasn’t satisfactory.

But only later did I realize that it wasn’t just the customers he was talking about. He was also talking about the salespeople, who never ceased to have reasons why they couldn’t or shouldn’t apply the policy in each particular case.

Recently, I found myself recalling that summer day, half-a-century ago, when a client asked me to find out why their Software Engineering Process Group was having so much trouble getting people to adopt new software tools. It couldn’t be the tools themselves, they reasoned, because quite a few people had adopted them and liked them. So, I set out to interview both adopters and rejecters, to discover the reasons some were using the tools and some were not. Here are some of the answers I obtained:

Darlene: I installed it because the boss told me to use it.

Porter: The boss told me to use it, so I didn’t use it.

Ursula: I installed it because the boss forced me to use it.

Marcy: The boss forced me to use it, so I installed it, but I don’t use it. He wouldn’t know the difference.

Quentin: I used it because it was like what I used before, so I knew I wouldn’t have any trouble adapting to it.

Chuck: Why should I use it? It’s nothing new; it’s just like what I used before.

Carl: Hey, I used it right away, because it was new and different.

Cynthia: I’m not going to use anything that’s new and different. Too many things aren’t tested, and something’s sure to go wrong.

Mary: Of course I used it. Everyone else was using it.

Roy: Everyone else was using it – what a bore! You won’t catch me following the crowd.

Frances: Why should I use it? Nobody else was.

Edgar: Hey, I got to be the first one to use it!

Mort: I couldn’t use it. It didn’t do all the things I needed.

Alan: The thing I liked best about this tool was that it didn’t try to be a Swiss army knife and do everything anyone could possibly want.

Gerri: It was the perfect tool, because it had every feature I could possibly want.

Chico: Every time I hit a key by accident, it would invoke some obscure feature that I didn’t want in there in the first place. Finally, I trashed the whole thing.

Orion: I’m so busy, I needed a new tool to save me some time.

Belle: I’m so busy, I don’t have time to install and learn a new tool.

May: I’m not that heavily loaded. Why would I need a time-saving tool?

Paul: Well, I wasn’t so busy with other things, so I had time to install and learn a new tool.

Earl: It was freeware, so it was a bargain.

Justine: It was shareware, so it couldn’t have been any good.

Jacob: This tool costs $3,000. It must be good, so I’m using it.

Neelie: I’m saving the company $3,000 by not using it.

Willis: I won’t use it because I don’t like the way Microsoft makes software.

Samuel: I knew it would be good because Microsoft makes it.

—–

Well, there were more, many more, but that’s enough of the infinite reasons to make my point. By this time, you may have noticed that I have arranged these reasons in pairs. Why? So you could see the pattern that I saw:

Every single reason to use the tool was matched by the same reason for not using it – and vice versa!

In other words, these reasons may look like logic, but they’re not logic – they’re just reasons. In logic, the reasoning comes first, then comes the decision. But in real life, it’s usually the other way around – first we make the decision, then we make up whatever reasons we need to “justify” the decision and make it look like logic.

And why would we go to all this trouble? Somewhere along the line, we’ve learned that emotional reasons aren’t good enough, so we have to fool people into thinking we’re more rational than we really are – so they’ll leave us alone to do what we intend to do in the first place.

I recently read about a fascinating psychological experiment conducted in a large office at the high-speed copier. When there was a line of people waiting to use the copier, an experimenter would walk up with a handful of papers to copy and try to butt into the front of the line.

In one set of trials, the experimenter would say, simply, “I want to copy these.” People were indignant, and refused to let him get in front of them.

In a second set of trials, the experimenter would say, “I want to copy these because my boss needs them.” People then willingly let him go right to the front of the line. In other words, if the experimenter had a good reason, then people were willing to let him go first, even if meant they had to wait longer.

But the fascinating phenomenon was in the third set of trials, where the experimenter would say, “I want to copy these because I need to copy them.” And guess what? The people let him go to the front, just as they had done when he had a “good reason,” even though this “reason” was totally vacuous. In repeated trials, the experimenters discovered that any “reason” would work, as long as they used the form, “I want to copy these because X.”

We seem to be conditioned to respond to this kind of pseudo-logic, and we instinctively know how to use it. Imagine telling your boss, “No, I’m not going to use this tool.” You know that the next thing you’re going to hear is “Why not?” So, you’re never dumb enough to “just say no,” but, instead, you’re going to say, “No, I’m not going to use this tool because X,” where you supply the X from the list above or from your own favorites. You might get an argument, but half the time the conversation will simply end there. And, if the boss does continue, you’ll then supply reason Y, then Z, then A, B, C, and D, until she gets tired of the game and quits.

But I’m not telling you all this so you can beat your boss in The Big Game of who gets to tell who what to do. I’m telling you because one of these days – perhaps today – you’re going to be on the other side of the equation. You’re going to be the change artist trying to introduce something new – a tool, a process, a document, a technique, anything new at all. And when you try, you’re going to find yourself faced with an infinitely high wall piled with reasons, mortared in place with that word, “because.” [Or "so," or other forms of pseudo-logic.]

And what will you do then? Rather than go back and forth with a potentially infinite chain of “why-because,” save yourself some time and energy by recognizing that you will always lose this game, so switch to another. One of these new games is to try to convert to real logic.

When you get the first “because,” simply say, “You’re right. There are lots and lots of reasons why you might not want to do it this way, and you’re exactly right to start raising them. Let’s carry this through.”

Then you take out a sheet of paper and draw a line down the middle. On the left, you label the column “Reasons Why Not.” On the right, “Reasons Why.” Then you write their reason in the left column and ask for one in the right column. If they can’t come up with one, prime the pump by showing how their own reason could just as well go on the right.

Continue filling out the columns until you have 6 or 8 or 10 reasons on each side, then say, “Okay, now let’s consider what’s the real problem here.” And off you go, possibly getting into real logic for a change.

A second approach is to short-circuit the game right at the beginning. When they start listing “why-not” reasons, you interrupt and say, “You’re right. Not everybody is right for this tool. Since you don’t have the right qualifications, I’ll go look for someone else.”

Sometimes, they’ll let you go – and then at least you’re saving time. But sometimes, they’ll stop you and start giving reasons why they are, indeed, the right people for this tool. And you can be sure they’ll have an infinite number of them.

About Gerald M. Weinberg

For more than 50 years, Jerry (Gerald M.) Weinberg has worked on transforming software organizations. He is author or co-author of many articles and books, including The Psychology of Computer Programming. His books cover all phases of the software life-cycle. They include Exploring Requirements, Rethinking Systems Analysis and Design, The Handbook of Walkthroughs, Inspections, and Technical Reviews, and General Principles of System Design. His books on leadership include Becoming a Technical Leader, The Secrets of Consulting, More Secrets of Consulting, and the Quality Software Management four-volume series. His book, Weinberg on Writing: The Fieldstone Method, appeared in 2005. His first techno-thriller novel, The Aremac Project (Dorset House), will appear in 2007. Email Jerry or visit www.geraldmweinberg.com to read excerpts of the Shape Forum. Picture (c)2004 Steven M. Smith
This entry was posted in Articles and tagged , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>