Three Samples to Read: People Skills—Soft but Difficult

Over more than half-a-century as a "technical consultant," I've learned that most of the problems I've seen are not fundamentally technical problems, but problems arising from people—problems solved or prevented by the application of so-called "soft" skills."

When we call these people-skills "soft," we imply that they are "easy" problems. Not so. If anything, they are hard problems—especially for those of us who have chosen some "technical" profession.

I've gradually developed some skill at handling such "soft" problems. I've also developed some skill at teaching others to improve their ability to solve such problems. "Teaching," of course, is another one of these "soft" skills. Writing is yet another "soft" (but not easy) skill, and I have written a number of books on a variety of "people skills."

My clients have often asked me to write one giant book covering "all the people skills," but such a book would have to have more that a thousand pages, so I have not done so. (One of my people skills is understanding that there are few people who would even attempt to read a thousand-page book.)

Recently, though, one of my clients pointed out that I had already written much more than a thousand pages on people skills (duh!). Once I let that "obvious" information into my thick skull, I realized that I knew a way to make some of those pages more readily available to my readers. And so I created a bundle of seven e-books anyone can buy at a saving of 25% of the original prices.

To help you decide if this bundle is for you, I've created the following sample of small lessons clipped from three of my books.  You can read and enjoy these samples and decide if your own "people skills" could be improved by reading dozens of such little lessons, plus a number of large lessons in the form of pragmatic models of human behavior. If your answer is "yes," then I invite you to purchase the bundle—risk-free, with Leanpub's "100% happiness guarantee."

So, here they are. Enjoy!

Sample #1: Discussing the Indiscussible 

(from More Secrets of Consulting)

Over the years I’ve come to believe that they key moment in an relationships occurs when one or both partners feels there’s something that can’t be talked about. This could be one thing, or many things, and for a lot of different reasons. When that moment arrives, the one thing that must happen is that the two partners talk about that thing. 

As a consultant, one of the most important things I can do to improve relationships is get that indiscussible subject out and on the table—but that seems risky. When I begin to fear this risk, I remind myself of the terrible consequences I’ve seen when the partners don’t discuss the taboo subject.

For instance, I was asked to work with Bill and Sherman, the co- developers of a software product who weren’t talking with one another. In this case, the thing that Bill and Sherman needed to talk about was that the Sherman didn’t want to talk to Bill. He didn’t even want to talk about the fact that he didn’t want to talk to Bill, so I decided to approach the subject indirectly, to reduce risk. I went to see Sherman and showed him my Courage Stick, letting him hold it and feel it’s smoothness. 

“It’s nice,” Sherman said. “What is it?” 

“It’s my Courage Stick. I brought it with me because I wanted to talk to you about something and I was a little afraid you might not like it.” 

“You, afraid of me? I’ve never seen you afraid to say anything.”

“Oh, I get scared about lots of things I need to say, but my Courage Stick reminds me that there are also fearful consequences when important things aren’t said.” 

“Like what?” 

“Like if I don’t tell you what will happen to your company if you and Bill don’t talk about some essential subjects. Like how you’re going to have a product that sucks, and how everybody is going to infer that Sherman is a lousy software architect.” 

You see, I didn’t know why Sherman was afraid to talk to Bill, but I knew that this would tap into one of Sherman’s greatest fears and change the Fraidycat Formula. I never tried to get Sherman to admit that he was afraid of talking with Bill, and after a little more coaxing, I led him by the elbow down to Bill’s office. I stayed for a while to act as referee, but soon Sherman’s fear was a thing of the past. Later, Bill told me that it took a lot of courage for Sherman to approach him. I didn’t bother to correct his impression. 

Sample #2: Changing Geography

(A case study from Becoming a Change Artist)

Change is a long-term process, but a living organization lives in the immediate present. Thus, without careful management, long-term change is invariably sacrificed to short-term expedience. And short-term expedience is taking place all the time, everywhere in the organization, essentially out of the view of high-level management. That's why change artists have to be in every nook and cranny, as the following case illustrates.

DeMarco and Lister have given us much useful information on the effects of geography on software development effectiveness. One manager, Ruben, reading Peopleware, was inspired to change the seating geography to improve customer relations. His semi-annual customer satisfaction survey had given the developers very low marks on communication. So, instead of seating people for efficient performance of today's work, he wanted to seat them to encourage communication, by putting eight developers in the customers' offices. However, when he surveyed customers six months later, Ruben found a large decline in their satisfaction with communication, precisely in those offices into which he had moved a developer.

What had typically happened was this. The developer would move to the customer's office and set up shop. Communication improved, but the first time there was a software emergency, the developer would rush back "home" to get the problem solved. Emergencies were rather frequent, and soon the developer would find it expedient to establish a "temporary" office in the developer area. 

After a while, the temporary office was occupied 99% of the time. In terms of the Satir Change Model, the foreign element—Ruben's move—had been rejected. Even worse, the customers were left staring at an empty office they were paying for, which reminded them of how hard it was to communicate with developers. 

Ruben noticed, however, that in one customer's office, satisfaction increased. In that office, the scenario had been different. Polly, a customer and change artist, sat in the office next door to Lyle, the developer, and noticed how often he was missing. She listened to comments made by other customers, and then she took action. 

Interviewing Lyle, she discovered that there were two main reasons why he kept leaving to solve problems: 

• The PCs in the customer office had less capacity than the ones in the developers' office, and that capacity was needed to run debugging tools effectively. 
• There were two other developers Lyle needed to consult on most of these problems, and they still resided in the developers' office. 

Polly knew these were typical problems of the Integration phase of the Satir Change Model, so she simply arranged to have Customer Service upgrade Lyle's PC. She then explained the benefits of having the two developers come to the customers' office, which was, after all, only two floors away. They were only too glad to come, and the customers were fascinated to learn how much work it was to fix "simple" problems in software.

With Polly as Lyle's neighbor, Ruben's strategic concept was implemented. Without using his survey to connect the strategic and the tactical, he would never have learned that it was possible to make the new geography work, and the success would have been limited to Lyle's area. Polly was sent around to the other developers who had moved, and she managed to get five out of seven working smoothly by similarly upgrading their PCs and encouraging developers to solve problems close to where they occurred. 

Polly also had the change-artist's skill to recognize that the remaining two departments were having deeper problems with information systems—problems that wouldn't be solved by upgrading PCs or encouraging proximity. Indeed, she saw that proximity was only making matters worse because the people were unskilled in handling interpersonal conflict. Thus, instead of blindly applying the same solution to everyone, she suggested to the managers that certain people could benefit from training in teamwork skills. 

Sample #3: Context-Free Questions

(from Exploring Requirements)

Once we have a starting point and a working title for a project, our next step in the project is invariably to ask some context-free questions. These are high-level questions posed early in a project to obtain information about global properties of the design problem and potential solutions.

Context-free questions are completely appropriate for any product to be designed, whether it's an automobile, airplane, ship, house, a jingle for a one-minute television commercial for chewing gum, a lifetime light bulb, or a trek in Nepal.

In terms of the decision tree, context-free questions help you decide which limb to climb, rather than which branch or twig. Because context-free questions are independent of the specific design task, they form a part of the designer's toolkit most useful before getting involved in too many enticing details.

Context-Free Process Questions

Some context-free questions relate to the process of design, rather than the designed product. Here are some typical context-free process questions, along with possible answers for the Elevator Information Device Project. (Notice that because these questions are context-free, we don't need to understand anything about the Elevator Information Device Project, an example started earlier in the Exploring Requirements book).

To appreciate how these questions can always be asked, regardless of the product being developed, also try answering them for some current project of yours, like "Trekking in Nepal."

Q: Who is the client for the Elevator Information Device?

A: The client is the Special Products Division of HAL, the world's largest imaginary corporation.

Q: What is a highly successful solution really worth to this client?

A: A highly successful solution to the problem as stated would be worth $10 million to $100 million in increased annual net profit for a period of five to ten years. The product should start earning revenue at this rate two years from now.

Q: (Ask the following context-free question if the answer to the previous context-free question does not seem to justify the effort involved.) What is the real reason for wanting to solve this problem?

A: The Elevator Information Device Project is a pilot effort for a range of commercial (and possibly even home or personal) information transfer devices. If we can demonstrate success during development and early marketing phases, this project is expected to spawn an independent business unit with gross revenues in seven years of $2 billion per year.

Q: Should we use a single design team, or more than one? Who should be on the team(s)?

A: You may choose whatever team structure you desire, but include someone on the team who knows conventional elevator technology, and someone who understands building management.

Q: How much time do we have for this project? What is the trade-off between time and value?

A: We don't need the device before two years from now because we won't be ready to market it, but every year we delay after that will probably reduce our market share by half.

Q: Where else can the solution to this design problem be obtained? Can we copy something that already exists?

A: To our knowledge, nowhere. Although many solutions exist in the form of control and information display panels for elevators, the approach adopted here should exploit the latest in sensing, control, information display, and processing—so copying doesn't seem appropriate. We have no objection to your copying features existing elsewhere, and you should be aware of what else has been done in the field, so you can surpass it.

Potential Impact of a Context-Free Question

Are context-free questions really worth such a fuss, and why do they need to be asked so early? Let's look at another example—extreme but real—of an answer to the second question, "What is a highly successful solution really worth to this client?"

At 3 a.m., a man in dirty jeans and cowboy boots showed up at the service bureau operation of a large computer manufacturer. Through the locked door, he asked if he could buy three hours' worth of computer time on their largest machine—that night. The night-shift employees were about to turn him away when one of them said, "Well, it costs $800 an hour. Is it worth $2,400?"

"Absolutely," said the cowboy, who emphasized the urgency by pulling a large wad. of $100 bills from his pocket and waving them at the employees on the other side of the glass door. They let him enter, took his payment in cash, and allowed him run his job on the machine. It turned out he owned a number of oil wells. As result of his computations, and especially the courteous treatment he received, he bought three of the giant machines, at a cost of some $10 million. If the employees had assumed the answer to the "What's it worth?" question based on his appearance, there would have been no sale.

The People-Skills Bundle

To learn more about all 7 books in the bundle, take a look at 

https://leanpub.com/b/peopleskillssoftbutdifficult

If you like what you see, buy the bundle with its 100% happiness guarantee. And perhaps you have a friend or two who could profit from reading their own copy.

The Art of Bugging: or Where Do Bugs Come From

Author's Note: When I first published this list in 1981, it was widely distributed by fans. Then for while, it disappeared. Every year, I received a request or three for a copy, but by 2000, I'd lost the original. This month, when closing up our cabin in the woods, it turned up in the back of a file cabinet. Inasmuch as I've been writing recently about testing (as in Perfect Software), and as it seems still up-to-date and relevant, I decided to republish it here for the grandchildren of the original readers.

Not so long ago, it wasn't considered in good taste to speak of errors in computer systems, but fashions change. Today articles and books on software errors are out-numbered only by those on sex, cooking, and astrology. But fashion still rules. Everybody talks about debugging—how to remove errors—but it's still of questionable taste to speak of how the bugs get there in the first place. In many ways, the word "debugging" has injured our profession.

"Bug" sounds like something that crawled in under the woodwork or flew through a momentary opening of the screen door. Misled by this terminology, people have shied away from the concept of software errors as things people do, and which, therefore, people might learn not to do.

In this column, I'd like to shift the focus from debugging—the removal of bugs—to various forms of putting them in the software  to begin with. For ease of reference, I'll simply list the various types of bugging alphabetically.

Be-bugging is the intentional putting of bugs in software for purposes of measuring the effectiveness of debugging efforts. By counting the percentage of intentional bugs that were found in testing, we get an estimate of the number of unintentional bugs that might still be remaining. Hopefully,  we remember to remove all the be-bugs when we're finished with our measurements.

Fee-bugging is the insertion of bugs by experts you've paid high fees to work on your system. Contract programmers are very skilled at fee-bugging, especially if they're treated like day laborers on a worm farm.

Gee-bugging is grafting of bugs into a program as part of a piece  of "gee-whiz" coding—fancy frills that are there to impress the maintenance programmers rather than meet the specifications.

Knee-bugging is thrusting bugs into a program when you're in too much of a hurry to bend your knee and sit down to think about what you're doing. We have a motto—"Never debug standing up." We could well extend that motto to bugging: "Never bug standing up."

Me-bugging may involve numerous forms of bug installation," for it refers to the method by which they are protected from assault. The programmer regards any attempt to question the correctness of the code as an assault on his or her value as a human being. Those who practice "egoless programming" are seldom guilty of me-bugging.

Pea-bugging can be understood by reference to the story of The Princess and the Pea. The princess showed her true royalty by being able to feel a pea through a hundred mattresses, illustrating that no bug is too small to be noticed by computers or other royalty. The pea-bugger,

however, pops in little bugs with the thought, "Oh nobody will ever notice this tiny glitch."

Pee-bugging is the rushing in of bugs when the programmer is impatient to attend to other matters, not necessarily the call of nature. The pee-bugger is the one who is always heard to contribute: "Lets just get this part coded up so we can get on to more important matters."

Plea-bugging is the legalistic method of forcing bugs into software. The plea-bugger can argue anyone out of any negative feeling for a piece of code, and is especially dangerous when walking through code, leading the committee around by its collective nose.

Pre-bugging is the art of insinuating bugs into programs before any code is written, as in the specification or design stages. We often hear the pre-bugger saying, "Oh, that's clear enough for the coders. Any moron could understand what we mean."

Re-bugging is the practice of re-introducing bugs that were already removed, or failing to remove bugs that were found and supposedly removed. Re-bugging is especially prevalent in on-line work, and some on-line programmers have been known to collapse from malnutrition when caught in an endless loop of debugging and rebugging a related pair of bugs.

Sea-bugging is named for the state of mind in which it is done—"all at sea." The typical sea-bug splashes in when everyone is making waves and shouting, "We've got to do something!" That something is invariably a bug—unless it's two bugs.

See-bugging is the implantation of bugs that "everyone can see" are correct. See-bugging is done in a state of mass hypnosis, often when too many susceptible minds are pooled on the same team or project. This unhealthy state prevails when management values harmony over quality, thus eliminating anyone who might make waves. Of course, too many wave makers leads to sea-bugging, so programming teams have to be constituted as a compromise between harmony and healthy discord.

S/he-bugging is done all the time, though nobody likes to talk about it. S/he-bugs have a way of infusing your code when your mind is on sex, or similar topics. Because sex is a topic unique unto itself, all s/he bugs originate by what might be referred to as sexual reproduction. That's why this is such a populous class of bugs.

Tea-bugging is the introduction of bugs when problems are solved during tea and coffee break conversations and then not checked before passing directly into the code.

The-bugging (pronounced thee-bugging) is crowding multiple bugs into a program under the "one-program-one bug" fallacy. The addicted the-bugger can invariably be heard ejaculating: "I've just found the bug in my program."

We-bugging is the ordination of bugs by majority rule. When someone doubts the efficacy of a piece of code, as in a review, the majority votes down this disturbing element, for how can three out of five programmers be wrong? Thus are born we-bugs.

Whee-bugging is a symptom of boredom, and frequently arises when Agile programming and other bug-prevention schemes have become well-established. Programmers reminisce about "the good old days," when programmers proved their machismo by writing code in which nobody could find bugs. One thing leads to another, and eventually someone says, "Let's do something exciting in this piece of code—wheeeeeel"

Ye-bugging is a mysterious process by which bugs appear in code touched by too many hands. Nobody knows much about ye-bugging because every time you ask how some bug got into the code, every programmer claims somebody else did it.

Z-bugging is the programmer's abbreviation for zap-bugging. The zap-bugger is in such a hurry that it's unthinkable to use three letters when one will do. Similarly, it's unthinkable to submit to any time-wasting controls on changes to working code, so the Z-bugger rams bugs into

the operating system with a special program called ZAP, or SUPERZAP. Although Z-bugs are comparatively rare, they are frequently seen because they always affect large numbers of people. There's a saying among programmers, perhaps sarcastic, "All the world loves a Z-bugger."

So there they are, in all their glory, nineteen ways that people put errors in programs. There are others. I've heard rumors of tree-bugs, spree-bugs, agree-bugs, tee-hee-hee-bugs. and fiddle-dee-dee bugs. I'm tracking down reports of the pernicious oh-promise-me-bug. Entymologists estimate that only one-tenth of all the world's insect species have been discovered and classified, so we can look forward to increasing this bugging list as our research continues. Too bad, for we seem to have enough already.

Note added in 2015: Yes, we had enough, but many have been added. If you know of a bug we didn't list here, I invite you to submit a comment about it.