by Gerald M. Weinberg

In 1977, Tom Gilb and I published a book called Humanized Input: Techniques for Reliable Keyed Input. We hoped to improve the pitiful state of input design for computer systems, and ten years later, we imagined we were beginning to see some improvement. On-line systems were coming into vogue, and we expected their use could only improve the interface between humans and computers.

Alas, though some systems improved, there’s been a steady decline, especially in those parts of systems where the average user has to communicate something exceptional to a computer. Clueless developers of the computer system “design” whatever sort of interaction pops into their minds, while the poor user of their system has to conform to these designs, or else. It’s like arrogant nobles assigning tasks to powerless peasants. It’s a one-sided conflict?the developer side side has all the weapons. while the users have to take their lumps and just grin and bear it.

But the Medieval world had its checks and balances, something we need in modern computing. In ancient Denmark, the laws of chivalry required that if a noble should ever duel with the peasant, the peasant had the right to choose the weapon. The nobles were trained in fancy weapons such as swords and dueling pistols, but the peasants had a preference for pitchforks and cudgels. As a result, any sensible noble went to great pains to settle disputes graciously with any peasant, no matter how gross and crude they might seem.

We need something like a cudgel to redress the balance between ordinary people and poorly crafted systems produced by thoughtless designers. Cudgels and pitchforks, however, could be found around any peasant household. Furthermore, there was a legitimate reason for them to be there. If the nobles wanted to eat, they could hardly outlaw pitchforks.

One way to fight the arrogance and insensitivity of computers is to use your own computer as your cudgel, but you don’t have to own a computer to be arrogant and insensitive. For those readers who lack a peasant’s pitchfork experience, I have catalogued a number of specific thrusts and countermoves. I’ve learned these tactics from the enemy, from the online and paper forms I’ve had to navigate to request support, report bugs, reconcile billing disputes, claim rebates, or register products.

1. Insist that any communication with you will have to go through your computer, and thus conform to the computer’s requirements, because “everyone knows that computers cannot be made to change in response to every trivial problem that people are having.”

2. The required information will have to go on a form, one copy of which you’ll supply upon written request on another form.

3. They will have to use the original form?no copies, please. If they should make a mistake in following the simple and convenient rules, they may write another letter and request another form. Without the original form, “our computer might not be able to read it.”

4. Every piece of information requested on the form must be supplied. Nothing must be left blank, even when you already have that information recorded accurately in your computer’s files. To leave something blank would “require our computer to spend extra time accessing the information.”

5. Where information requested duplicates information already in our computer files it must be identical, character for character, including spaces. If someone asks you why it must be identical, you say that “our computer will be confused if it checks the information and finds differences.” If they ask why the information is needed, inasmuch as our computer is going to access the original in order to check, you reply that “the computer may decide not to check, and we can’t tell in advance which cases it might check.” (This is true by default because you don’t really have a computer.)

6. Every item you fill in on the form must adhere strictly to our specified format, otherwise reject the form. Don’t accept alternatives that might be clear to human beings, because “they will require extra coding steps.”

7. The specified formats must be chosen to be unfamiliar to people, such as,
a. Last name first, first name last
b. Fill in all leading zeros, the more the better
c. Year, day, month
d. Local phone exchange, number, then area code
e. Zip code, followed by street address, then state and city
f. Numbers in scientific notation
g. Binary coded numbers
(And, yes, believe it or not, I’ve encountered each of these cases.)

8. Because you can’t be certain that the formats in [7] are unnatural to people accustomed to working with computers, require that each time a similar item is needed, a different format is requested. For instance here are some variations in the dates I have had inflicted on me:
a. 2009 July 17
b. 17/7/09
c. 17/07/09
d. 17 VII 2009
e. 17-JUL-09
f. 7,17,09
g. July 17, 2009?but be careful of this one, it’s almost understandable.

9. When numbers are needed, it’s best to have them be as long as possible. If they don’t have any long numbers, make up some. Since human memory is pretty reliable up to seven digits, it’s best to require at least 10 digits, but do not allow any internal punctuation. If you ask for 234-789-4001, they might get it right half the time, but 2347894001 will cut that percentage down to size. Also, every extra digit beyond 10 will pay huge dividends in erroneous forms, which can then be returned with rude notes implying inferior intellectual development. An effective technique is to pad out the number with large numbers of leading zeros, as in 00000002347894001. (How many zeros is that, anyway?)

10. If you can get away with it, use at least two pages, back-to-back, for paper forms. A second page gives lots of special possibilities, such as,
a. Information on the back that has to be copied onto the front, and vice versa.
b. Information on the back that’s needed to understand the items on the front, and vice versa. For instance the set of codes that are to be used on page 1 can be listed on page 2. This technique works well with pages on websites, too.
c. Consecutive pages should be printed on opposite sides of one very porous and translucent sheet of paper. This technique guarantees that material from the other side will show through when copying. It also allows ink to flow through from one side to the other. Naturally, you don’t allow pencil, and require both sides to be clear of extraneous material.

11. Because multipage forms allow copying from page to page, you have the opportunity to impose difficult copying tasks. For instance, on page 2 you can require copying the form number from page 1, just to make sure that “the two sides of the paper don’t get separated.” An appropriate form number is 1783562812354678-1A.

12. Limit names and addresses to 20 characters each?or 18 if you dare?but do not allow truncation. If Daniela Schimmelpfennig complains, tell her she has no right to have a name that confuses computers. Suggest that she change her name to something more reasonable. Or, simply truncate her name in any way you like? Daniel Schimmelp, for example.

13. When a limited field is required, allow far more space on the form than is allowed in the computer. For instance, if a number is limited to 12 digits, use a 13-digit space on the form. If possible, make no comment, but if your conscience bothers you, write an instruction saying, “For type A use leftmost 12 digits. For type B, use rightmost 12 digits.” Be sure there are several A’s and B’s on the form, thus creating doubt as to which is meant. This technique ensures that at least half of the forms will be wrong just as if you had given no instructions.

14. Where the required information is essentially unlimited in length, use a space that is patently too small. An excellent example is these instructions:
“Please explain your problem in your own words, giving all relevant information that might bear on our providing you with better service in the future.” Then limit the response to 40 characters and/or follow this instruction with a space no longer than three quarters of an inch.

15. If you can’t make the instructions actually contradictory, as suggested in [12], at least use sufficient jargon to ensure that they can’t be understood, as in [13]. If you do this well, the people using the form will feel like fools.

16. Jargon from [13] can be combined effectively with instructions given in the form of computer programs as in
“If the audit interval is greater than the contemplated discount, then enter the appropriate rate code from the conversion table on page 2 in place of the discount code, unless the audit interval falls within the operating system recovery. Or line 17 of page 2 will be left blank when following the instructions on that page under item 2.1.7.3.9.2.4/a.”

17. When giving programmatic instructions, it is best to have at least one backward reference, such as (on line 5-1 on page 2), “If this figure is negative, change the value in line 17B., page 2 to zero.” Working in ink, this is sure to confuse, but just in case they have the sense to make a trial copy, include at least one cyclic reference. For instance, back on line 17B on page 2, you could say, “if this value is zero, change any negative value online 5.1, page 2, to positive.” (Notice the inconsistent notation: 5-1 in one place, 5.1 in another. Inconsistency always helps increase confusion.)

18. Set rigid deadlines for receipt of the form, and indicate that if the deadlines are missed, you cannot guarantee any particular date for a response. Then mail the blank forms so they arrive on the deadline date. (The next day is not as good as some people just give up in despair. It’s better if they try to meet impossible deadlines and spend much money on special postage.)

19. Naturally, the forms may not be folded, spindled, or mutilated in any way.

20. Following these rules when responding to cyber crud ought to equalize the odds a bit in the never ending battle of peasants against the nobles. But just in case the above 19 rules don’t quite convince them that you actually have a computer, here’s one more that’s sure to crush all the remaining resistance:
Make sure your form is 1 mm wider than the handy return envelope you provide.

A Word to Designers

Maybe next time you design one of these interfaces, you’ll take off your cloak of nobility and, for a few minutes at least, don the shabby rags of us poor peasants who are forced to use your product. You can do that, because, like me, you’ve also been on the peasant’s side more than you’d like.

convert this post to pdf.

©2007 Gerald M. Weinberg

Throughout my career, I’ve watched in dismay as one software manager
after another falls into the trap of achieving delivery schedules by
trimming tests. Some managers shortcut test work by skipping reviewing
and unit testing in the middle of their project. Others pressure the
testers to “test faster” at the end. And, most frequently,
they just drop planned tests altogether, hoping they “get
lucky.”

I’ve written several essays about the dangers of test trimming,
but nobody seems to understand, so I asked myself, “What am I
doing wrong?” Perhaps I wasn’t practicing what I was preaching.
Perhaps I was trimming tests myself. Perhaps my writing needed
more testing!

So, I wrote a story about taking shortcuts and read it to my
granddaughter, Camille. Here’s the story:

Rhubarb Cakes for the Queen of the Forest

Once upon a time, all of the animals in the forest were in an uproar.
Calling Crow had just proclaimed that in two hours, the Queen of the
Forest would arrive for a visit to choose a new Royal Baker.

“She’s going to hold a baking contest,” Calling Crow cawed.
“And the winner will be named Royal Baker?and win a prize of
100 pieces of gold!”

“What do we have to bake for her?” barked Burly Bear.

“Rhubarb cakes,” Calling Crow cackled.
“They’re her very favorite dessert.”

Rapid Rabbit ran nervous circles around a rhododendron bush.
“Rhubarb cakes? But the Queen is coming in just two
hours, and my recipe for rhubarb cakes takes three
hours.”

“So does mine,” complained Canny Coyote.

Burly Bear sharpened his claws on the bark of an ancient aspen.
“Mine, too.”

Prudence Porcupine popped up and headed for her kitchen.
“Then I think I’d better get started, and not just stand around
complaining?”

Each of the bakers pondered how they could make their rhubarb cake
in two hours.
“I’ve got it,” thought Rapid Rabbit.
“What takes the longest time is putting in a little sugar at a
time, stirring for five minutes, and tasting to see if it’s just right.
I don’t really have to test the sweetness a little at a time. I’ll just
throw in the right amount of sugar all at once, and that should save me
an hour.”

Burly Bear reasoned to himself,
“I have the biggest oven, so I can put the cakes on the top
shelf, in the very back where it gets super hot. And I can stoke the fire
with lots and lots of apple wood because that burns hotter than any
other wood. If I bake the cake at a higher temperature, I can save a
lot of time and have it ready when the Queen arrives.”

Canny Coyote didn’t have such a big oven, but he figured,
“if I just cut an hour off the baking time, the cake might be
a little soft, but I’ll put in lots of sugar.
The cake will be so sweet that the
Queen won’t notice.”

But Prudence Porcupine had a different way of thinking.
“I know my rhubarb cakes are delicious, but if I take any shortcuts,
I’m pretty sure the cake won’t come out right. I’ll just tell the Queen
that my cake is going to be late, but that it will be worth
waiting for.”

When the Queen arrived, Rapid and Burly and Canny all had their
cakes on display in the clearing, and the Queen was invited to taste
each cake in turn.

She took a bite of Rapid’s cake and made an ugly face.
“Yuck. This rhubarb cake is so bitter.
Why didn’t you add more sugar?”

Then she turned to Burly’s
cake and asked, “Why is this one all burned and black?
Well, maybe it’s better on the inside.”
But when she tried to cut a slice, the burnt crust was just too hard to cut.
Instantly, the Queen moved to Canny Coyote’s table
without even tasting the bear’s cake.

She tried to cut a slice of the coyote cake.
“This cake looks rather mushy.
Oh, it’s all gooey and runny when We try to cut into it.
We think it would make Us sick if We put it in Our mouth.”
(Queens always call themselves “We”
because they believe they are speaking for the entire nation.)
The Queen stuck out her tongue at the cake and refused to taste it at all.

Finally, the Queen turned to Prudence’s table and asked,
“Why is there no cake here? We distinctly said
that every baker was to make a rhubarb cake.
Who dares to refuse a Royal Proclamation?”

Prudence stepped forward, bowed to the Queen and said,
“My cake is in the oven, Your Majesty.
It will be ready for your tasting in one hour.”

“But We said the cake must be ready NOW
” shouted the Queen.
“That was a Royal Order, and cannot be disobeyed.”

Prudence bowed so low her quills caught some fallen leaves.
“Yes, Your Majesty. And I wished I could have made a rhubarb cake
in two hours. But I don’t know how to make a cake that
way that would be fit for a Queen, so I did my very best and took three
hours. If you want to punish me,
then you are the Queen and may do whatever you like.”

“Humph,” growled the Queen,
thinking of suitable punishments.

Prudence brushed away the stuck leaves.
“But the cake is in the oven now,
and you can just begin to smell how tasty it’s going to be.
In one hour, it will be fresh from the oven,
and a fit dessert for your refined tastes.
In the meantime, I’d be happy to tell you a story,
to make the time pass more quickly.”

“What story?” demanded the Queen.

“I thought I’d tell the one about the Princess and the Pea,”
Prudence offered. This delighted the Queen because that story was about her,
when she was a young princess. So the Queen listened to the story,
and laughed and cried and clapped so hard that an hour passed
by very quickly.

Then Prudence put on her mittens, opened the oven, and took out a
perfect rhubarb cake. The Queen loved it so much she ate the entire cake,
with just a small slice for Prudence. Then she gave Prudence a woven bag
with one hundred gold coins and announced to the whole forest that Prudence
Porcupine, though she was at times a little prickly,
was the Best Baker in the Forest and now would be the Queen’s Own Baker.

**********

When I was finished reading, I asked Camille what was the lesson
of the story. She said,
“Burly and Roger and Canny were not real bakers.
They were just pretending because they wanted to win the prize,
but they didn’t know how to bake a real cake.”

“Very good,” I said. “But maybe they did know,
but were afraid of the Queen.”

“If you’re afraid to do what you know is right,
then you’re not a real baker.”

Camille, who was not yet five years old, understood this story perfectly,
so it passed my test.

I wonder if forty-year-old software managers will be able
to understand it?

convert this post to pdf.

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

On a typical day, I get 100-200 email messages, and some of my clients in large projects receive even more. Though emails improve my ability to communicate clearly and quickly, they may also prove a hindrance to certain kinds of communication. In particular, email does not adequately serve as a medium for recording an important agreement. An important email may be too transitory, too easily lost among volumes of less important communications, too easy to misunderstand, and too easily lead to unnecessary conflicts.

Although email can reduce the need for personal contact, it cannot entirely eliminate contact between teams building components that must work together to form a system. Separation of teams tends to create language differences that lead to misunderstood emails. Teams develop local goals that may diverge from project goals and actually conflict with other teams’ goals. With different language and divergent goals, interfaces stop being stable, clear, stakes in the ground. Instead, they can easily become the disputed border between two warring states or two different cultures. To prevent border wars, I prefer the ancient solution – writing and signing treaties.

A software treaty is more or less identical to a treaty between political units. I like my treaties to be written on a single piece of paper with a fancy border, like a gilt-edged stock certificate. A typical treaty might contain.

1. A reference to the technical terms being agreed to – such as a reference to a specific version of a document in the project’s repository.

2. A statement that all signatories agree to the technical terms in (1).

3. A statement that the treaty will remain in effect unless and until renegotiated among all the signatories.

4. Dated signatures of each team’s official representative – most often the team leader. The treaty implicitly recognizes the independence of the signatory teams and their ability to enter freely into agreements on technical matters.

5. (Possible) Management signatures witnessing the treaty.

Although a manager quite likely acts as facilitator to the negotiations, treaties will not work if parties are coerced into signing something they don’t understand, or don’t agree with. Nor will they work if some affected party fails to participate in the negotiations and sign the treaty, so management must ensure that all affected parties are represented.

After signing, however, good management becomes mandatory to enforce the pact the parties agreed upon. In other words, once each party freely gives its signature, the matter is no longer a purely technical one, but becomes political.

Why political? Because after the agreement, one party could disrupt the project and/or make the other party look very bad by covertly changing the agreement. A written treaty seals off this avenue for expressing any animosity or mistrust that exists between the parties. When people understand that management will rigorously enforce each treaty, they can quit bickering and get down to the business of building. Moreover, teams can work with the assurance that anything not in a treaty is not a commitment – and will not become a commitment without going through the treaty process.

With signed treaties covering all interfaces, no single team can disrupt the project by covertly changing the rules in the middle of the game. Woe to any team that fails to meet the interface specifications agreed upon in their treaties.

What happens if one party to the treaty decides they made a mistake, or got a poor deal? For instance, during the negotiations, I might have agreed to pass error-free data in return for two milliseconds more of execution time, but now I find that I cannot scrub the data that fast. I can then call for a renegotiation, but I may have to trade something else for the relief I seek – even something that will simplify my enemy’s job.

Such a concession may prove a bitter pill for me to swallow, especially as the renegotiation is done in front of management, but I have to understood that unilateral changes to my treaties will damage the project and make my life much less pleasant.

The startup of a treaty system will sometimes seem awkward, unfamiliar, and overly formal. I know from history, however, that this degree of formality is needed if former antagonists are to work together cooperatively. White ties are optional, however, and quite soon the awkwardness dissipates.

We frequently see one party resist actually signing a treaty, but such resistance always indicates that the resisting party is uncertain. Because the whole treaty process is designed to eliminate uncertainties, resistance tells me what I want to know that there is still more definitional work to be done.

Treaties are especially helpful for contractor professionals, who may rush into a poorly understood commitment in their eagerness to improve their cash flow. But no matter how much I hope that the definitional job is finished, the strong commitment implied by a signature prevents me from mistaking hope for reality.

By keeping communications on the level of reality, rather than hope, I may create a few problems today, but I avoid bigger problems tomorrow.

By making agreements between cooperating parties a strategy for peace, I avoid the hardest problems of all, the misunderstandings that lead to interpersonal conflicts.

convert this post to pdf.

©2000 Steven M. Smith

I’m forty-five, with a mainframe background. I often hear complaints from colleagues — associates who are my contemporaries — that younger workers with experience in hot, new technologies are getting paid as much or more then them. They are certain that twenty years of experience in the industry entitles them to higher pay. Surveying my contemporaries, I am certain that some of them do have wisdom that is worth more pay. But I am just as certain that some of my contemporaries aren’t worth any more pay than a younger or less experienced worker.

I reached my conclusion after amusing myself with a comparison between me today and me in my early twenties. To simplify this written comparison I’m going to refer to me twenty years ago as “Young-Steve.”

Young-Steve was a monomaniac on a mission. He was fanatically dedicated to his work; twelve or more work hours per day was normal. He intuitively understood that his most marketable asset was his thirst for knowledge and relentless drive. So Young-Steve worked and worked and worked. He thought older colleagues who seemed less dedicated than he were less valuable. For instance, Ed — one of Young-Steve’s older colleagues — told him that, at night and weekends, he would put his telephone in the refrigerator to avoid after-hour questions about his System from the Operations staff. Although the quality of Ed’s System was excellent, he seemed lazy and unprofessional to Young-Steve. It would take some years for Young-Steve to understand that Old-Ed had other relationships that were more important to him than work. Young-Steve couldn’t understand how anything could be more important than work. But he would learn.

Young-Steve saw a world where everyone in computing played the “waiting game” for pay increases. Young-Steve was a computing whiz kid, so Management was happy to give him three jobs — and happy to pay him less than someone with ten years of experience who was only doing one job. Young-Steve thought those kind of pay decisions were weird, but learning about computing gave him so much joy that he didn’t care. Now it’s clear to me that Young-Steve deserved higher pay than someone with just “experience.” Today’s job market is more competitive, and if a younger person can do more they can get paid more. I applaud this outcome — it’s long overdue.

How would I stand up in a competition between me versus Young-Steve? Because of Young-Steve’s thirst and dedication, he would positively outdo me when it came to learning and exploiting new technology. The quality of his products would be, given his understanding of the requirements, excellent. Of course, Young-Steve would work to his own requirements, rather than the customer’s, and his decisions would sacrifice economy and delivery speed for quality every time. Young-Steve lived for his work, so delivery delays and extra hours seemed more than a fair tradeoff for a quality product. Hell, for Young-Steve the extra hours were fun.

I would positively outdo Young-Steve at understanding the customer, exploring their requirements, making explicit tradeoffs, and delivering a product tailored to the customer. I would also outdo him if the product required a group effort. I know how to tap into the power of a group. Young-Steve had the potential to work with groups, but he preferred being a hero.

It’s tempting for me to say now that Young-Steve didn’t have a life, but I believe that statement is false. Young-Steve was very happy twenty years ago. He just measured his value almost exclusively from work. And with so much emphasis on work, Young-Steve neglected relationships away from work. That choice cost him dearly.

Who is more valuable, me or Young-Steve, depends on the type of work, and the customer. Young-Steve gets the check mark if the work is more than 80% technical. I get the check mark if the work is more than 20% about influencing other people. When the customer acts erratically, Young-Steve gets the check mark because he would do almost anything in his power to satisfy the customer. I get the check mark if the customers need help understanding what they already know and adding to that knowledge. Young-Steve gets the check mark for sacrificing his life away from the job for work to meet customer demands. I get the check mark if the work requires setting boundaries and pushing back.

I’ve tried to compare us, but it’s hard because there really wouldn’t be a competition. I’ve changed. The work that interests me wouldn’t interest Young-Steve. He would want a narrow focus on technology, and I now want to focus on helping organizations improve their productivity. Although Young-Steve would outdo me technically, I could compete in that arena: Young-Steve couldn’t compete with me in my new mission. He doesn’t have the skills yet.

Let’s look at me now. I no longer inflict my opinions on people. When asked by Management for my opinion, I try to be practical and realistic, rather than optimistic. I haven’t forgotten the hard lessons I’ve learned over twenty years. I work to get the job done, rather than working for the pure fun of learning. Token management awards for working long hours that would have excited Young-Steve now turn me off. A project schedule with months of long days no longer fits me and I won’t put up with that kind of workload for very long. I want a project that is under control and doesn’t squander my time.

Everyone doesn’t share that priority. In my experience, managers in many organizations believe their very survival depends on increasing delivery speed. Those managers sacrifice — many times unknowingly — quality and economy to satisfy their desire for speed. And if delivery speed is the principal force behind management decisions, then young people with raw, adaptable technical skills are more likely to accept that force more easily than older workers. Younger and less experienced workers, like Young-Steve, are optimistic and want to please. They are more willing to march to the beat of a project that other workers — people who know how to detect unhealthy projects — would avoid because they would diagnose it as a deathmarch.

The world isn’t fair and it never will be. Someone with five to twenty years of experience isn’t necessarily any better than someone with no experience. What we do isn’t union work, so seniority is a meaningless idea. I know people with twenty years of experience that haven’t learned a new thing in nineteen years. If you have gained wisdom — and it can’t be scheduled or guaranteed — then you’re worth a whole lot more than either the young technical whiz or the person with twenty years of not learning. One sign of wisdom is knowing how to sell the value of your wisdom to a customer or employer. If, on the other hand, you can’t figure out how to articulate your wisdom and how to do sell it, then you don’t deserve better pay than the young whiz kid working next to you.

convert this post to pdf.