PC Alamode Magazine Online - WhatsUp.Doc; Commentaries on Software Rage, K. Joyce McDonald

HOME

Calendar

Join / Renew

PC Alamode

About Us

HELP

Archives

Other

by K. Joyce McDonald

Index

WhatsUp.Doc

Working without a net
And other commentaries on Software Rage
May 2002

K. Joyce McDonald

Joyce is a senior technical writer for a local software company.

See her web page

I'm getting a lot of response from readers now, the content of which is quite good. If you write, be sure to let me know if I can use the content in an article and if you want me to use your name and/or e-mail address.

When I was a kid, my parents made it their dedicated parental duty to take my sister and me to every circus that came to town. My favorite part of the show was the flying acrobats, who enthralled me with their style, agility, precision and bravery. More fascinating than a perfectly-executed show, however, were the times when two acrobats didn’t quite connect, and the flying one would take a tumble into the net. The fallen one, with equal style and agility, would maneuver to the edge of the net and somersault out, making a bow when on the ground, as the audience responded with even greater applause than we heard after a perfect show.

Occasionally, one could view acrobats who worked without a net. The lack of a net then changed the nature of the show. It told you that these acrobats were so confident, their precision so exact, that they were willing to work without the reassurance of the net. After seeing multitudes of perfect performances, the audience no longer noticed that the net was not there.

Computer documentation is much like that safety net. The only time we notice it is when we need it and it isn’t there. "Software Rage" is the likely result. Granted, lack of needed documentation is not quite as disastrous as lack of a needed safety net. Still, a computer monitor is equipped with high-voltage capacitors that can deliver a powerful shock when a fist shatters its viewing surface, so perhaps we should detail its causes.

In a recent AnchorDesk Piece (March 5) Executive Editor David Coursey describes Software Rage as precipitated by inadequate or absent documentation. I offer the following excerpt from his column.

"Software rage causes sufferers to lose faith in their applications, their computers, Microsoft, the software industry, the people who represent them on the other end of the phone, technology as a whole, and in the most extreme cases, the entire human race...

"Software Rage Syndrome is the result of:

Software in which seemingly simple tasks are not explained in the help documentation.
Online help systems that make it difficult to find the solution to a problem, often because the specific text of error messages cannot be found in the knowledge base.
Software that no longer comes with printed documentation or any easy way for customers to print the online documentation, sometimes requiring users to run the application on two machines so the online help is available on one machine while the user manipulates the application on the other.
Internet service providers that provide Web-based help for Web-access problems, as though people who can't get onto the Internet could use the Internet to discover why not.
Companies that don't list contact information, sometimes at all or sometimes missing critical elements like a telephone number, on their Web site address.
Companies that label their products as being able to do something, then fail to provide directions for use — at all — in their printed or online documentation. . .

"Often, after experiencing one or more of the situations above, the user will attempt to contact the software publisher and have one or more of the following experiences:

Be sent through a bewildering telephone menu tree that leads the user to a dead end, where the problem isn't solved and no human help is available.
The user calls the company only to find themselves speaking to someone located half the globe away, who though very sympathetic is completely unable to help resolve the problem. Users with good problem-solving skills sometimes get curry recipes as a consolation prize.
A recording tells the user the "wait time" for assistance is in excess of 30 minutes and offers to record a message, which is then never returned.
The user is charged $35 to solve a problem or implement a feature that isn't fully described in the documentation or which does not work in the manner described.

I've been thinking about this because my friend David Pogue, the noted computer how-to author, coined the term "software rage" in a recent New York Times column.

"Pogue has made a nice fortune off bad tech support, by the way, so in calling companies to task he's really acting against his own self interest. His "For Dummies" and "Missing Manual" books do a better job of documenting software and solving problems than all but the very best tech support (of which there isn't very much)."

The day after Coursey’s “Software Rage” article appeared, David Morgenstern added fuel to the fire with his AnchorDesk article “Software rage: Why you're partly to blame.” The following excerpts from his article describe his theories.

"Computer owners and software developers seem to have fundamentally different visions of who should use programs, and in particular, who's responsible when things go wrong.

"Developer Candyce Hawk wrote in a long post about technical support. 'The bottom line is that software rage is not going to go away any time soon, because companies peddling software lack integrity for the most part, and end users want to be coddled and bottle-fed until they're 50 years old! I don't see this coddling mindset at all with people who are under the age of 20; they see the power in knowing how to do something already. So they are a piece of cake. Tell them one time and they'll do it themselves after that.'

"Tom Orr observed, 'The PC is not now, nor has it ever been, a consumer product. The problems arise when the industry markets them as a consumer product. Consumers expect products to just work. So don't blame tech support when the industry sells PCs designed for scientists and engineers as consumer products.'

"To software engineer Dave Haynie, the answer is simple: Customers must make support a bigger part of their purchase decisions. 'Do your homework. Check out the support sites, official and unofficial, and see the kinds of problems people are having, whether they're solved by company or community. Check the Web site for updates and see if they continually update the software or not.'

"Even the most consumer-driven business can have blind spots about their products. I recently found a monitor that ships without any printed documentation; it's all on a disc and online. Surely, everyone can see the problem here, except the manufacturer."

The title of Mr. Morgenstern's column was, I'm sure, tinged with irony. However, Ms. Hawk, Mr. Orr and Mr. Haynie's ansewers were sincere, if defensive.

To sum up Ms. Hawk’s, Mr. Orr’s and Mr. Haynie’s observations, the consumer:

Is too lazy and/or stupid to learn how to use software on his/her own, especially if he/she is over 20.
Has no business owning a computer unless he/she is an engineer or scientist.
Must do an extensive web search to find out which companies produce the buggiest software and offer the poorest tech support. (Of course, the consumer will have to purchase their software anyway, because it dominates the market, leaving almost no alternatives.)

Has Ms. Hawk ever considered that anyone over 20 is usually gainfully employed and therefore does not have the time for the trial-and-error approach to learning software applications? Most of us geezers, however, are glad to refer to documentation, if there is any.

I suggest that Mr. Orr petition his employer to pay him only for the percentage of his software applications purchased by engineers and scientists since he expresses no interest in creating anything useful for the rest of us.

Mr. Haynie's idea has some merit, however, it confirms the fact that the principle of Caveat Emptor is strongly enforced by the software industry. A better suggestion appears in the March 18 issue of NetworkWorld, where reader Bradley Gruber writes to Backspin columnist Mark Gibbs suggesting a software Lemon Law.

If you have been reading this column for a while, you know that I have spent the last ten years developing user guides, Web pages, online help systems, software release documents and program specifications for developers in the public sector, in the software industry and in telecommunications. Next month, I will offer insights from my personal experiences to explain why documentation is often bad or nonexistent.