I remember a briefing I once had with Oracle, where the Oracle marketing man proudly proclaimed that “we now have a Soundex capability.”

In case you didn’t know: The Soundex algorithm is a method for indexing names by sound, according to their English pronunciation. The idea is that names with a similar sound like Smith and Smythe will have the same index. It’s a simple algorithm that collapses any name into a 4 character code. Rumor has it that the algorithm was invented in an effort to sort out the names of English casualties in World War One – because many of the conscripts were not literate, so some of their names were recorded wrongly.

Replying to the Oracle marketeer I said, “but that only amounts to about 10 lines of C code.” The response burst his balloon. He had no clue as to how complex Soundex is to implement and he was astounded that I knew. It was an unlikely event, but he’d run into an analyst that had actually coded a Soundex search.

This is a powerful reason, by the way, for keeping a profile on analysts that you brief, with specific reference to their technical background and understanding. I was a software engineer once. That doesn’t mean that I’ll always be right about whether a software product is good or bad, but it does mean that I’m pretty good at “kicking the tires”.

Lies, Damn Lies and Heuristics

Listen to me! I have a software product to die for. It can develop applications that are much more sophisticated than are ever developed using Microsoft’s Visual Studio, or any configuration of Eclipse with any set of build tools. If it’s fed with the right information, it can duplicate or exceed all the functionality of SAP, including every one of its modules and likewise it can deliver anything that any of Oracle’s application portfolio can offer, or Microsoft’s for that matter.

And best of all, it’s free!

It’s the GNU C compiler.

You see, I didn’t tell a lie, but I mangled the truth so badly that it’ll never walk again.

In the 1990s when I used to spend a good deal of time evaluating development tools and CASE tools, I’d run into that dishonest kind of presentation again and again.

Probing into a product’s capability, I’d ask, “if you put water into it and boil it, can it make a decent cup of tea”.

And the marketeer would reply, “yes, we can achieve that via the low-level API,” which means “no”. And by the way, every technical analyst worth his sodium chloride knows that means “no”.

The Right Briefing Presenter

Just as you set a thief to catch a thief, you should send a technician to brief a technician. If you don’t, you risk having a poor opinion of your product proliferate. Even on a good day, an analyst with good technical skills is capable of assuming that the deficiency is in the product, as well as the presenter.

And by the way, that’s one of the reasons why IT vendors pay analysts to do message testing.

Note: This posting is one in a series of postings that deals with the topic of dealing with analysts. Click here for links to other postings in the series.