Computers Stink, by Jack Bellis

Chapters 1-3 <You are here
Chapters 4-7
Chapters 8-End

Note: This is a quick conversion of what had been a glued-binding book, to a 3 long HTML files. Over time, I'll improve the conversion. A single PDF (854K) and DOC file (774K) are also available.

Sadly, though this book was written in 1997, most of the complaints about software design are just as true today.

—Jack Bellis, March 11, 2003

How to Make Today’s Technology as
Productive as It Is Powerful

Jack Bellis

Computers Stink
This book is free to copy as you please. No copyright is claimed by the author.

ISBN 0-9655109-8-0

All brand names used in this book are the trademarks, registered trademarks, or brand names of the respective holders.

For Susan, Jessica, and all the computer users waiting for the promise to be fulfilled without the problems.


The table of contents has not been converted to HTML yet.

1. Introduction                                                                             7

Is This Book For You?                                                      8

Cut to the Chase!                                                           8

Mass Market Improvements Haven’t Filtered Down to Business Software  9

What About Popular Style Guides?                                   10

Topics in this Book                                                        10

Programs and the Complexity of Machines:  How Bad Is It? 11

About Me                                                                     12

My First Computer Idea                                               12

Changeable Neon                                                       12

Programming Mysteries                                               13

Ideas and Solutions                                                   15

2. What Do Users Expect From A  Program?  A Computer User’s Bill of Rights 17

3. The Underlying Problems                                                     21

One Central Problem                                                     21

Electronic Troubles                                                        21

Walking the High Wire                                                   22

A Beginner’s Guide to Backup                                      22

The Invisible World: Directory or Hiding Place?                  24

'Distributed Processing'                                                  24

Most Programs Are Only Half Finished                              24

User-Friendliness is Long-Term Marketing in a Short-Term Market    25

Lack of Knowledge or Concern                                         25

UNIX                                                                           26

Windows 95, or... Computers Still Stink                            26

4. The User Interface: Hit Any Key to Continue                    28

Importance of the Interface                                            28

What Is Human Factors Engineering?                            28

The Communication Burden: Interface or Documentation 29

Elements of the User Interface                                    30

The Machine Makes You a Machine                               30

There Are Very Few User Interface Designers                 31

Major Problems with User Interface Design                       31

Form Follows Function?                                               32

Most Development Starts Over Again from the Beginning 33

Complex Procedures That are Never Converted to Program Functions    34

Special Values that Never Get Built into the System       34

Bad Design                                                               34

Developer’s Indifference                                             36

Paranoia? Mistaking Secrecy for Security                        37

Lost Productivity Hall of Fame... Can You Guess?           37

No Usability Testing                                                   38

Rules For User Friendliness                                             39

#1: Put All (ALL ALL ALL) functions, Mouse Methods, Fancy Keystrokes, and Instructions on Menus                                            39

#2: Use Verbose Phrasing                                           41

#3: Use Perfectly Accurate Words                                42

#4: Be Explicit, Not Implicit                                        44

#5: Put All Orders on ‘Menus’: Alpha, Functional, Learning, Date  46

#6: Provide a Master Menu, Integrating All features       47

#7: Display from the General to the Specific                  47

#8: Always Let Users Navigate by Descriptive Values, Not Internal Codes     48

#9: Use Buttons as an Additional Option—Not an Alternative—to Menus       50

#10: Put Functions Where Users Will Look for Them       51

#11: Always Show the Level at Which Options Are Invoked 51

#12: Use Dynamic Communication, Not Dynamic Menus and Dialogs    52

#13: Always Provide Visual Cues                                 53

#14: Default to Saving Work                                       54

#15: Tune for Learning, Not Just Cruising Speed            54

#16: Usability Testing                                                55

#17: Build Error Message Details Right into the Program 55

#18: When the User Does Not Have Control, Announce it Prominently  56

#19: Use Color to Speed Recognition, and Sound for Feedback    56

Some Not-So-Easy Recommendations                              57

Microscope: Detailed View of Internal Data                    57

Trace: Detailed View of Program Commands                  58

Layer-Testing Diagnostics                                           59

Mixing Metaphors                                                       60

5. The Nine Levels of Help                                                        61

1. None                                                                       61

2. Bad Books or Help                                                     61

3. Good Books                                                              62

4. Good Books, Online, Context Sensitive, Interactive        62

5. Better Books                                                            62

6. Good Programming                                                    63

7. User-Sensitive Help                                                   63

8. User Contributory Help                                               64

9. Wizards: Step-Through Dialogs                                   65

Summary                                                                     65

6. PC Hardware                                                                         67

Modular Hardware?                                                        67

Write It Down                                                              69

The Computer as a Household Appliance                          71

7. Documentation: One Step Forward, Two Steps Back      73

Why Documentation Stinks                                             73

Reason #1 Why Computer Books Stink: Insufficient Emphasis on Valuable Information                                                           73

Reason #2: Books Are Often Written From 'Specs'          75

Reason #3: Companies Expend Resources on Superficial Editing, Not Usability Testing                                                                75

Reason #4: ‘Cookbooks’ Without Troubleshooting           76

Reason #5: Failing to Roll the Books Back into the Product 77

To Print or Not to Print...                                               78

What is the Real Issue?                                             78

Strengths of Paper and Electronic Documentation           78

Put All of the Information Online                                  78

Print a Short Read-Through Guide                                 78

What Should Be in a Read-Through                              79

Videos and Other Passive Learning Tools                          80

8. Inside Computer Programs:  'Source Code'                      83

Make Descriptive Terminology a User Option                     83

Provide Menu Support For Program Syntax                         85

9. Training                                                                                  87

10. Support and Troubleshooting                                           88

Knowledgebases                                                           88

A Primer on Technical Troubleshooting                             89

Questions to Ask About Support                                      90

11. Action Summaries                                                               92

So What Are You Going to Do About It?                           92

Actions for Hands-Off Executives                                     93

Actions for Purchasers of Software                                   94

Actions For All Users                                                     95

Actions for Programmers                                                96

Actions for Development Managers                                  97

Actions for Tech Writers                                                 97


I’ve got to stop writing this book! But every day I come home from work with more examples of how much time is being wasted with stupid, avoidable computer problems. There seems to be no end. To make this book, I’ve taken every example and asked myself, “How could computer software be improved to make the problem go away?” I’m convinced that a significant portion of the answers are now contained in the following pages, so I will force myself to stop and leave the results in your hands.

Just remember as you read, I’m not opinionated, I’m right.

Those who agree with us may not be right,
but we admire their astuteness.”
          — Cullen Hightower

1. Introduction

I called a professional printer to get an estimate on producing the book you are reading now. His estimating software crashed as he was entering the job information—yes, really. He said he’d call me back.

Productivity. That was the promise, right? And what a payoff we got. I can now operate the equivalent of a publishing house from my home office. With programs like Ventura Publisher or Macromedia Director, I can learn in weeks what used to take a lifetime apprenticeship, and get results with a fraction of the time and money that used to be required. That’s the good news. But the average computer user does not go half a day without some sort of unnecessary frustration, problem, or time loss. That’s the bad news that I want to turn around.

The printer whose program crashed was using an estimating program that he had created himself, and he probably deserves a lot of credit for the accomplishment. In fact, he gave me the first part of the pricing information in a matter of seconds, just before the program had a problem. This put him head-and-shoulders above the other printers I called, who all seemed to act as if obtaining a price estimate required conjuring spirits. So his experience was very typical: computers both elevate his business and make it more frustrating. Go figure.

This book describes why computer programs are so difficult to use, why more time is often lost than gained, and what can be done about it. The concepts discussed in this book apply to all software and hardware, and the perplexing array of technologies and activities that intertwine the two.

Take your own informal survey of computer efficiency—I did. Ask the people you work with when the last time was that they wasted time with a computer problem. Then ask them what percentage of time they think they lose to those problems. I routinely get responses of “yesterday” and “10-20 percent.”

Is This Book For You?

Most of the recommendations in this book are for programmers and their bosses. But you will benefit from this book if you use or buy programs, or manage people who do. Even if you don’t, you should find much of interest here, if you are 'Howard-Beal-mad-as-hell' about the troubles you've had using computers and want to understand why, whose fault it is, and what to do about it.

Cut to the Chase!

No matter how easy this stuff is, I don’t suggest that it is common sense. If it were, it would already be common practice.

By some estimates, businesses spend  more on computer technology than on the natural gas, automotive, petrochemical, steel, and mining industries combined. Now imagine how the results of your survey impact such a huge expenditure.

In a nutshell, more technology—in and of itself—is not the answer. But the entire computer industry loves to make you think it is. That way, they can foist on us all the latest techno-miracle, and by the time we realize it hasn’t reduced the inefficiency, they’ll have another one.

The current flavor-of-the-month is called Java, the latest in an endless parade of programming languages, which developers must learn again from a standing start. According to the industry it cures cancer, makes you live forever, and gives you wealth beyond imagination. According to me, it’s another distraction from the real goal: following through on established practices to fully capitalize on the great technology that we already have.

Mass Market Improvements Haven’t Filtered Down to Business Software

Programs and the Complexity of Machines:
How Bad Is It?

About Me

My First Computer Idea

I've used computers since 1982. At that time, I had an idea for a program, bought a cheap computer, and thought I'd make the necessary program and sell it. Although I didn't have any expectations about how long it would take me to make the program —I had no experience in programming— I suppose I thought it might be several months.

Two years later, the program was ready to sell. In the interim, I learned just how far computers had come in a few short years and just how far they still had to go if they were to fulfill the expectations that had developed.

Changeable Neon

I particularly remember one night when I stayed up ‘till about 4 AM trying to get letters to scroll smoothly across the top of the screen. (A coarse, bumpy, scroll was built into the machine, but smooth scrolling required something akin to decoding the Rosetta Stone.) When I finally got it, I thought it was the happiest day of my life. It was the hardest problem I had solved since Rubik’s Cube.


Pretty exciting stuff, eh? (I’ll bet some of you propeller heads are out there mumbling to yourselves, “Add accumulator 7, store accumulator 212...”) To make a long story short, the whole thing taught me that computers stink. No matter how much more powerful they keep getting, the power doesn’t seem to consistently translate into productivity. The same mistakes seem to occur time and time again. With each new technology, we seem to start at the beginning again. All over the place the machines are mastering their users instead of vice-versa. Why?

Ideas and Solutions

In the words of the immortal Howard Beal of the movie Network, I'm mad as hell and I'm not going to take it any more. I've used hundreds of computer programs, learned 17 languages for talking to computers, and I've seen the same mistakes repeated over and over for 14 years now...

I've seen one company after another have endless meetings to solve the same customer support problems... I've suffered through the same troubleshooting scenarios on my own and coworkers' computers time and time again... and I've heard the same excuses over and over. And, while I see improvements, they’re hit-or-miss. I don’t see organized, steady progress.

2. What Do Users Expect From A  Program?
A Computer User’s Bill of Rights

You shouldn't have to read a manual,
certainly not a huge one.

For large business systems, certainly manuals might be unavoidable. But documentation is not a substitute for making the user interface do most of the work. It’s true that many of today’s programs replace what was once a lifelong apprenticeship with what is now a $100 program. The training required to eventually equal the skill of the trained artisan might still take a considerable investment of time and energy, but good programs make it possible to get results with a minimum of effort.

 I recall reading in a recent book about the Internet that it takes a certain seriousness of effort to jump the first few days’ hurdles of navigating the net, because all programs must choose between power and friendliness. That’s nonsense—it’s the same old excuse we’ve been hearing forever. One software house after another is proving this false.

Ø      Hitting Enter gives you today’s date.

Ø      If the user enters a single digit, such a 8, the system assumes he means the 8th of the current month, and fills in the full date January 8, 1996.

Ø      If the user enters 3 or 4 digits, such a 110, the system assumes that the final two digits are the month (for DD/MM/YY users such as in the U.S.) and interprets the date as January, 10 of the current year, 1996.

Don’t think of this page as intentionally blank...
it is ‘paragraphically challenged.’

3. The Underlying Problems

One Central Problem

There is one central problem that is ultimately at the root of all of this trouble:

Electronic processes are invisible to the naked eye.

More to the point, the inner workings of the computer are so microminiaturized as to be completely beyond our ability to cope when things are not entirely as we expect. Almost all other problems are really results of this one deadly killer; don't be fooled.

What Can You Do?
Use every countermeasure to battle against the most hidden aspects of the computer. Improve the hardware, software, documentation, training, purchasing demands, support, and record keeping. Insist on every countermeasure that increases the visibility of the machine’s inner workings. That’s what the rest of this book is about.

Electronic Troubles

How can I blame so much on so singular a factor? The limiting factor with today's computer systems is not their performance when things are working right, but their ability to frustrate us when things are less than perfect. With mechanical systems, by my rough estimate, one in three people can understand or even fix a problem; two in three can at least understand what's causing the problem. This is even true for what are called 'electro-mechanical' systems such as automobiles of the 1960's.

But once electronics enter the scene, I’m sure the numbers change dramatically for the worse. Perhaps only one in a hundred people can diagnose an electronic system. In fact, true root-cause diagnosis is almost never done. Instead, whole electronic modules and even whole products are replaced when there are problems. This is often done without genuine diagnosis, but with a process that requires less expertise: swapping parts in a crude process of elimination. Too many times the underlying problem goes unresolved and rises again to destroy the newly installed part.

From a troubleshooting perspective,
computers are an insidious subset of electronic appliances, exacerbating the already disastrous nature of electronic troubleshooting with more levels of intricacy and variability.

In the sentence above, it took me a long time to settle on the word 'disastrous,' after rejecting softer alternatives such as difficult, troublesome, and untenable. Too strong a word? Tell that to the folks at a nuclear power plant. Or how about the many folks who insist that their automobiles accelerated without their having pressed the gas pedal?

I hate having electronic appliances fixed because I expect the repairman to replace what is essentially the entire electronic device. At one point, our house had a microwave oven that worked whenever it wanted, a TV remote control that worked by appointment only, an electronic air cleaner that worked sometimes, and a furnace fan that worked incessantly when the mood struck it—all electronic marvels.

What can you do?
Make sure at every step of the way that you are mastering the technology and not vice versa. Strive to understand the layers of technology that have brought us to this level of performance, or get people who do.

Walking the High Wire

What can you do?
Get down from the high-wire every so often.  Prove that YOU determine when you get up and down, not the technology. Do backups and prove you can restore them. Test your operation with various aspects of your computer not functioning.

If failure can happen, you can bet it will happen at the worst time, and it’s not always just coincidental bad luck. Many system failures occur at the worst times because those are the times when the system is stressed or tested the most. Expect the unexpected.

A Beginner’s Guide to Backup

The following advice is primarily for users who are relatively new to computers. If you’ve never lost any work on a computer, you are relatively new! Computer backup has at it’s core a very simple tenet realized a long time ago when thrill-seekers would perform stunts on the wings of flying airplanes:

The first law of wing-walking: don’t let go of one wing until you grab hold of the other wing.

If you’re a computer veteran, of course, the following advice is unnecessary for you... right?

Ø      Establish your pain threshold for repeating work, and save your work that often. In other words, let’s say the most work that you could bear repeating is 20 minutes of work. Save your work every 20 minutes. If your program has an automatic, timed backup, set it for 20 minutes. And even though you have an automatic timed save, still save your work manually every 20-30 minutes.

I have to interrupt this good advice for my most recent computer horror story. I was using the previously-most-popular word processing program in the world recently when it started giving me trouble. It would freeze, indefinitely, and wouldn’t let me enter any text, click on anything, or even restart it without restarting Windows 95.

Then I noticed that it was happening like clockwork. Aha! I turned off Timed Backup and the problem went away. Something was making the Timed Backup fail, and instead of issuing a message, the best it could do was its own version of what some folks call the Black Screen of Death. Let this be a warning to you—I just don’t know what the warning is.

Ø      Once a project consumes more than a day of work, save at least one older copy under a different name, still on your hard disk drive. Having only a single copy of your data on your hard disk drive is a prescription for misery. Sooner or later you will use a program that corrupts your data and the authoring program will not be able to read the copy of the file you are working with. By having an alternate version, you can revert to that one.

Ø      After adding days of work to a project, copy your data files out of your computer to another medium such as a diskette. Sooner or later your hard disk drive will fail due to static electricity, voltage surges, electronic deterioration, disintegration of the magnetic drive surface, or degradation of the rotating mechanism.

Ø      After working on a project for more than a few days, get your backup diskettes or tape out of the building. I keep copies of this book in my car, to protect against theft, flood, and fire, and randomly rotate new copies back and forth to the car or office.

When I worked at the Franklin Institute, I took a trip one time to bring back an entire holography laboratory. I came back after museum hours, so I put everything away as well as I could. The only problem was a big can of holographic film , about the size of a five-gallon paint drum—it had to be put in the refrigerator, which was behind locked doors. After looking around a little, I found a good spot. Being in the basement, the cool weather made the ten-foot-deep window wells a good choice.

I hesitated as I walked out our door, thinking to myself, “What are the chances that someone will come in our shop to clean the window wells for probably the first time in the 70-year history of the building... no, don’t be paranoid, it says in big letters right on the can, “Holographic Film, Do Not Expose To Light.”

The next morning, I was busy with some chores when I passed by the building engineers walking into our shop as I walked out. Halfway down the hall, my eyes bulged out and my neck stiffened. What are they doing in our shop!? Yes, less than 10 hours from the return of my trip, the basement window wells of the Franklin Institute were being cleaned. I’m certain it was the first time ever, and yes, the can was already open, the bright yellow Kodak label lying on the ground, the three layers of tape ripped from around its tightly sealed top, and the dark black paper peeled back. As I told you, expect the unexpected.

Months later, I learned that much of the film ended up working quite well. I don’t know how much was lost.

The Invisible World: Directory or Hiding Place?

One of the most repetitive problems with software is just finding your work. The typical computer disk drive has hundreds, sometimes thousands, of directories. With the DOS limitation of 8-letter filenames, most organized folks create a deep hierarchy of cubbyholes in which to store their many projects. The result is that the disk drive can become a huge hiding place, despite its surprisingly compact size. But programs and operating systems have made slow, hit-or-miss progress at addressing this problem.

All applications, utility programs, and operating systems must take more responsibility for finding things. Search features must not be treated as an afterthought or optional accessory. Features which search or sort must work across all directories and disk drives.

What can you do?
1) Create separate directories for all categories of data. When in doubt about whether a directory should be a subdirectory or at the same level as the previous one, make it at the same level.
2) Store all of your creations in subdirectories under a directory named MYDATA or similar. Name them by project purpose. Don’t store them with the relevant authoring programs, as many programs encourage you to do.
3) Store all of your programs in subdirectories under a directory named MYTOOLS or similar.

By relegating all projects and tools to two subdirectories, the highest level directory on your drive (the root directory) will be less cluttered, which will make your directories easier to work with. And it will be easier to identify what must be moved or copied when it is time to rebuild your system or move it to another machine or hard drive. That day will surely come.

'Distributed Processing'

A trend that is now only a few years old, called distributed processing, is taking things to new extremes of frustration. Distributed processing means splitting up programs into pieces that are then put on multiple computers instead of on a central system. It is synonymous with ‘client-server’ computing and has resulted in software solutions that use between seven and ten layers of technology.

Eventually this approach will be refined to a point where a successful balance is reached between the costs and rewards of this complexity. Until then it is a pot of gold for software developers because creating the full solutions—not simply the programs—is an incredibly tenuous process, fraught with finger-pointing at ever turn.

None of distributed processing’s problems are unique. Its problems are simply more and ‘better’ versions of what the technology already offers: invisible behavior, poor diagnostic methods, piecemeal engineering, and for the pièce de résistance, new state-of-the-art tools every month.

Most Programs Are Only Half Finished

The pressure to be first to market is intense in the computer business. You know that. It’s one excuse that most programs don’t do everything they should. As programming standards have improved, we are starting to understand just how much a program can do when it is as good as it can be. The recent method which Microsoft calls a wizard is, if not the ultimate, close enough. Wizards prompt you for the minimum required information, and lead you by the hand through what would otherwise be a complex process. An example is presented in Chapter 5, The Nine Levels of Help. In earlier generations of programs, such processes would have been lengthy written procedures in the documentation, supported by many separate menu functions of a program.

But wizards demand the ultimate expenditure of effort from the programming staff. After all of the basic functions have been built into a program, a wizard puts them together, adds elaborate instructions, and even makes assumptions and suggestions about how those functions will be tied together. The following quote, possibly attributed to Peter Norton, a prominent computer expert, summarizes this unfortunate tradeoff for users:

There is always a tradeoff between the convenience of the programmer and the convenience of the user.

Another way of saying it is that good user interface design takes more work. Wizards, however, are only one type of thorough program, one suited to predictable procedures.