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.

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState