Written by David Tebbutt, MacUser 04/91 item 02 - scanned
Have you ever wondered why software publishers are so hopeless at technical support? I guarantee that the minute you run into a serious problem, especially if it's their fault, the helpfulness evaporates to be replaced with a sort of "you must be doing something wrong" attitude.
In one of my other lives, I am involved in developing PC applications. The quick and dirty programs are written in BASIC, while those requiring a bit of oomph are done in an assembler. (I know I should be using C or C++, but that's another story.)
One of my customers called me the other day to say that a program I wrote no longer worked on his PC. I asked him what he'd changed recently. He'd replaced his hard disk for a whopping great big one and he'd moved from MS DOS 3.3 to DOS 4.01. If DOS was as upwardly compatible as it is supposed to be, then the problem might lie with the hard disk. And, if it was the operating system, I knew there was no chance of Microsoft changing it just for me.
I called the hotline at Borland who told me they no longer supplied TurboBASIC, but that this problem was well-known: my version of TurboBASIC cannot access disk drives larger than 32M. The solution, they said, was to buy the latest version, now called PowerBASIC. They were very helpful, giving me the address and telephone number of the UK PowerBASIC supplier. They also told me I could pay a special upgrade price, which just happened to be more than I paid for TurboBASIC in the first place.
I called the supplier, Megatech, which confirmed that the new language would solve all my problems. So, £84 later, I was the proud owner of PowerBASIC. I recompiled the BASIC program that was giving me problems, took it round to a friend who used large disks and DOS 4.01 and, guess what? The program didn't work.
I called the hotline and, after I convinced them that I really had paid for the program, was told, "Well it can't be PowerBASIC, because your program worked under DOS 3.3 and anything written for that will work on 4.01." This was patently untrue, otherwise I wouldn't have been on the phone. Eventually, I decided to rewrite the disk handlers. It worked, of course. What I still haven't checked out is whether my new BASIC program would have worked anyway under TurboBASIC.
A week or so after that bit of excitement, I decided to turn my attention to FileMaker Pro. When I first got it, I tried transferring my old FileMaker II stuff to the new release. It didn't work so, being the impatient type, I immediately gave up and returned to my original copy of FileMaker.
A few weeks ago I read (in MacUser, I think) that if you save FileMaker II files in compressed format, they can be read into FileMaker Pro and all will be well. (I must admit that I found it odd that Claris hadn't checked FileMaker Pro for compatibility with FileMaker II. What's the matter with the company? Doesn't it have any beta testers?) Still, I did the compression and reading and it worked a treat. I'm sure the new release runs slower than the old one, though.
It's not the speed of FileMaker Pro that irritates me so much as the fact that the manual is wrong. I wanted to go through a database of 500 records, assigning one value to a field under certain conditions and another value if the conditions weren't met. I read the manual and realised that the Position command would do the trick. I carefully typed the calculation definition only to be greeted with a 'field not found' message applying to all of the arguments in the Position command.
I must have retyped the instruction a dozen times, exactly according to the manual, not believing my eyes when I kept getting the error message. In the end, I decided to use the very easy menu facilities to build the commands. And guess what happened? While the manual insisted that arguments are separated by commas, the menu separates them with semi-colons. What a complete waste of time. And how avoidable too. I'm sorry, Claris, I like your products but you didn't earn any brownie points for that little shambles.
I know that software publishing is very difficult. The more complex the products, the more difficult it is to check out every combination of circumstances. Writing manuals when a program is still in the final stages of development is a thankless task, and, trying to find staff who are up to the job of technical support is nigh on impossible.
But I can't help thinking that, in their rush to get product to market, software publishers spend far too much time on the hype and too little time on the vital stages of beta testing, manual checking and support staff training.