Who Ya Gonna Call?

I've been reviewing software and books and such for Linux Journal for a few months now, and I have been enjoying the experience. Occasionally, I find that asking some questions of the software producers enables me to give a fairer review. I've discovered this research portion of reviewing is sometimes more entertaining than the actual item being reviewed. Companies will send things to LJ for revie

One example would involve an outfit we will call (to protect their identity), the Surfing Sufis. These lovely people produce a rather large package of software that inspired a rather large passel of questions for my review. So, I called the Surfing Sufis' Software Support Desk and asked if they'd be so kind as to put me through to the people who are directly responsible for this particular software. The woman on the end of the phone was very warm, solicitous and willing to help. So was the gentleman to whom she connected me...as was the lady who answered the next transfer.... This auditory "square dance" endured for about an hour, with one fellow (support person #4, if I recall correctly), unofficially appointing himself as "caller" for the duration.

Nice folks, these. Not informed, perhaps, but nice. It was rather unfortunate, then, that informed was what we were going for. I've not heard so many apologies in one hour since I was a small child at a dance in a roomful of less-than-sober adults. Still, it warmed the heart.

The "ace" up my sleeve was another contact in the Surfing Sufis, a little higher up in the organization. I thought, given her position, the person in question might have an idea, or at least she would have access to an individual who might know the person I should talk to. So I wrote to "Madame Ace", who fired off an e-mail to "Mister Incognito", asking him about the matter.

And neither was ever heard from again.

(Remember that old bumper sticker "This project's so secret even I don't know what I'm doing"? It's like that, only with real people. At least the CIA generally gets a "who's who" of their members.)

Several other scenarios evolve from the simple inclusion of little business cards with books and software submitted. These usually bear the names of publicity agents/marketers/promoters and the like. These cards are sometimes stapled, sometimes paper-clipped to the item. One tends to interpret this as a sign of important documentation.

If the number on the card is correct, odds are good there is neither a voice nor voice-mail on the other end of the line. If either of these is present, the absence of actual knowledge about the product will be relatively conspicuous with the wave of a single question. Their stock answer (not as in a script, but as in "repeat after me" sessions ) is, "you'll have to call the company for that". At which point, thank them, tell them they've been most helpful and make a point of tongue-biting. Restraint isn't, however, a virtue--it's an instance variable.

There are inquiry e-mails that don't get answered, and one eventually wonders whether or not the individuals have been too busy, too flustered or too shy of media attention to understand that an e-mail answered will cover a multitude of "skins". It's certainly easier to answer questions than to defend the project staff who decided to include a rather interesting format of documentation with the software. The Fortran code may read better than most of the honorees on bestseller lists; however, if humans are not briefed in a language appropriate to them about what they are to do, results can be a bit slippery. (Fish, whether from infamous towers or nor, write appalling translations of anything).

There is one other small loophole for the giggles. This involves the rare instance where the publicity person actually gets back to you, blissfully unaware of things like, oh, timezones. I say "instance" because when Madame Gung-Ho Publicitious has called you at 5:30 in the morning, and you have gone to bed not two hours before, events tend to evolve in such a way as to ensure, without rancor, profanity or belligerence, that Madame Gung-Ho-Publicitious will not call you back. Probably ever, but at least not for several months. She will go red with embarrassment when her supervisor or client asks how things are progressing with that review of their product. She will have to either admit that she woke you up at a time when even the deities in your locale are a-slumber, or muffle something about having caught you "at a bad time". Neither confession is going to make brownie points with the one who's curious about her efforts. People asking agents about such things tend to be very boolean in their appraisals.

IT is a serious business, after all. COBOL coders know this. Reviewers know that people are generally fallible, affable and malleable. After they've written their reviews of a product, reviewers read other reviewers...and lose sleep realizing someone had more fun than they did.

Author's note: I wish the preceeding events were fictitious. They aren't. However, I've made every attempt to conceal the identities of the companies and individuals involved. If a name appears here, (other than, perhaps mine and that of Linux Journal), and it actually happens to belong to a company or individual in existence somewhere, you will have to take my word for it that that company is not the one referred to here.

Stephanie Black is a writer--of words and code. When not writing, she runs a Linux consultancy, Coastal Den Computing, in Vancouver, BC, Canada.

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix