John Klonick in Lee Gomes’ December 6 column, Wall Street Journal:

My son, a student at Texas Tech University, had managerial accounting test recently. We were nervous about the test because he is repeating this class, having made a “D” the first time. He called us, jubilant, and told us he had completed the test in 30 minutes. So why weren’t we as happy as he?

We both had the same reaction: he must not have seen all the questions (perhaps he didn’t turn the test paper over and see the problems on the back?) Or he didn’t complete his answers the way he was supposed to.  And he probably didn’t proofread his answers to make sure they made sense.

Having been a high school teacher for many years, I used to cringe when any student finished a test in less than the allotted time and immediately left the paper on my desk. “What’s your hurry?” I would ask. “Don’t you want to go over the paper and re-think any of your answers? Or maybe proofread your essays?”

I’m sure that some of those students are now working in the Tech sector, because I run across the same issue when documenting software and reviewing the existing documentation. When updating or reviewing a manual or help system, I see that the previous author had not bothered to proofread the text or test the instructions against the software. Or perhaps the author’s manager did not bother to check the instructions or assign a coworker to check them. Having no documentation to guide them, tech writers often have to guess at the way a function is used and what it is used for. This is why the manager must arrange to have someone knowledgeable test the manual for correctness.

If I was writing the manual from scratch, I often came across features in the software that acted quirky or did not perform according to the specifications. It is my duty to report these problems, but the persons with the power to fix the problem or implement solutions sometimes took a cavalier attitude toward the problem. In such a case, my only recourse was to gloss over the error or make the instructions a little muddy so that the user would not be sure how the software was supposed to work in the first place. I hated doing this.

Consider the following comments from Lee Gomes in Wall Street Journal (10/28/02)
 

In another article, Mr. Gomes comments,

You can rest assured that the technology sector is racing towards the next “biggest and fastest” goal. But perhaps instead of racing, they should be strolling, taking time to check their work. Taking time to make their interfaces understandable. Taking time to test and retest and document. And re-document.

Commenting on Software Rage, published in the May, 2002 issue of PC Alamode, I wrote:

I recently received a response from Ms. Hawk regarding those comments. She quoted my May commentary:

Ms. Hawk’s comments:

If someone has paid good money for a software application, I doubt that this person has any resistance to learning. What I see in software is a resistance to teaching, exhibited in the form of illogical software with poor or inadequate documentation.

Fifty years ago no one had to read a two-hundred page manual to learn how to use the telephone. If you needed it, contact with Customer Support (A.K.A., Operator) was almost instantaneous (Dial 0 or in many locations, just stay on the line) and I doubt that the operator sported an attitude that someone asking for help was a learning-impaired geezer.

The fact companies opt to spend $10 an hour for customer support in lieu of spending  $20 or more an hour to have some decent documentation written speaks reams about the industry’s hostility toward the user.

I’ve heard it all a million times: We don’t write manuals because the users don’t read them. Even when we write manuals and users do read them, they don’t understand them. What they don’t say is that it’s easier to blame the user than it is to make the application more understandable and produce a manual that is more readable. So you guys out there — poor software quality is all your fault, so buck up and learn.