Recently, we both recognized that my Palm IIIx has overtaken the coveted space at the apex of my adoption continuum. I don't go anywhere without it and am constantly finding new uses for it, including jotting down new column ideas for PC Alamode. My husband has been impressed with my ability to locate bits of obscure information, such as directions to a house we visited a year ago, our original purchase price for a mutual fund or the product number for our vacuum cleaner bags.

So impressed was he with my Palm usage that he decided to buy me a new color, top-of-the line model so I could pass my old one on to him. Since we were Handspring stockholders, however, we decided to buy a Visor instead of a Palm.

My Visor Prism had great color, an expansion module for a digital camera, and that wonderfully simple Palm operating system. I had a ball with it for about two weeks, until it quit working.

I won't go into the gory details— just the facts. I asked if I could handle the issue via e-mail since I was hearing impaired. They e-mailed me the troubleshooting instructions, and I followed them carefully. I e-mailed them back with detailed results of each procedure. They responded by letting me know the unit needed to be replaced. They told me to e-mail back the serial # along with my name and address, and they would send me a mailer with instructions for the return. I immediately responded.

After two days, I got another e-mail saying that they did not handle this sort of thing by e-mail, and I would have to have someone call for me. I e-mailed them back with a copy of their previous e-mail detailing how they handled a return via e-mail (since it is obvious that they didn't read their own e-mail.) I never received another e-mail from them.

A week or so later, my husband called customer service, gave them our address and serial number and received some terse mailing instructions (none of which could not have been sent via e-mail.) According to UPS tracking, they received the package several days ago, but I have yet to hear from Handspring.

Were I to tell this tale of woe to your standard technology sector manager, the response would be, "What's the issue? They all do that." Indeed, they do. Could this endemic lack of integrity be the reason for the current crisis of confidence in the technology sector? Could this cavalier attitude toward the customer be the reason why potential new users are dragging their feet when it comes to upgrading or adopting new technology? Could this unveiled hostility toward the user be the reason why companies like Microsoft are now devising methods to force their users to upgrade by building an off-switch into Windows XP?

If you read my May column on Software Rage, you learned that many software developers short on integrity and long on opinion would like to blame you for being too lazy, stupid or uneducated to learn to use their programs. This attitude is reflected after the fact in their inadequate customer service, and before the fact in inadequate documentation.

Of the developers I quoted in my previous article, not one of them mentioned lack of documentation as a source of user frustration. Nor could they be expected to. Almost universally, software company executives, officers and developers consider documentation (along with unpaid customer service) to be an unnecessary luxury.
Depending upon which managers the documentation person works with, he/she may have to deal with other issues and opinions that stand in the way of adequate documentation.

Some marketing departments favor withholding some documentation from the user for several reasons:

• The company may not want you to learn to use the software too quickly. If you read documentation, you might find that the software doesn't work the way it is supposed to. With no documentation or vague instructions, you are more likely to assume that the problem results from your own mistake rather than the developer's.
• Tech support has become part of their revenue stream. Once you decide the problem is yours, they can charge you to fix it.
• If the software interfaces with a program from another vendor, the company can blame the lack of performance on the other vendor. Software vendors usually enforce a policy preventing documentation developers from explaining issues involved with the interface or with the other software. The cooperating software company usually takes the same attitude, making the interface itself and the areas around it a no-man's land that never benefits from documentation.
• The worst, most vague documentation available is the "terms of use" agreement. A documentation specialist who tries to make an existing "terms of use" agreement readable may be told to put it back the way it was. If the "terms of use" agreement is written clearly, the user or potential user might actually read it and start asking questions. The marketing department wants to be as vague as possible about what it promises, what the software actually does, and what might be hidden inside.

Developers take the attitude that "real men don't ask directions," so why include documentation? Most developers take the attitude that their programs are so transparent that explaining how to use them is like including instructions with a pack of gum.

Of course the programs themselves are far from transparent because systems analysis is also considered an unnecessary luxury. Developers can get coding started sooner if they fly by the seat of their pants. This attitude makes as much sense as an architect insisting that it's quicker to build a house without wasting time on a blueprint. Of course, architects don't have the opportunity to sell maintenance agreements to correct the problems caused by inadequate design.

And the design itself? The developers I have worked with remind me of a perfectionist housekeeper mopping the floor. This floor must be the shiniest, best looking floor in the neighborhood, calling for the slickest polish available. Only when someone enters with wet feet and falls does the focus shift from how the floor dazzles to how it is used.

If the users demand documentation (as the users of $200,000 software programs are inclined to do), development managers grudgingly hire a technical writer at the lowest salary possible, and require him/her to work under the following constraints:

• Documents are due when the software is finished (whenever that is.)
• Writers are not to mess with our database. Find some other way to learn the software.
• Don't expect us to read your documentation, even if you had to guess how the software works.
• We reserve the right to change any screen at any time and not tell you.
• We do not want to hear from documentation about clumsy program logic, bugs in the software, or missing features. We have deadlines to meet.
• We do not want to have anything to do with the help system, so if our code includes erroneous calls to the help system, you fix it at your end, because we don't want you messing with our code.

Users get the same treatment whether they paid $20 or $200,000 for the software application. As a matter of fact, the $20 customers are tougher to please because they read reviews, talk to others, post their opinions on the Internet and are invested in whether they themselves can actually use the program before they buy. The $200,000 users aren't usually the ones who bought the software. The purchase decision was made several rungs up the chain of command, and the users are stuck with it.

I am certain that workers still exist in the real world who do a job as much for the satisfaction as for the pay, and who work to make the product better because it's the right thing to do. The question is whether any of those workers belong to the technology sector.