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.

______________________

Webcast
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers

Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.

Learn More

Sponsored by AMD

White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions