Why does software always crash irrecoverably when you're at your busiest? And why are technical support lines unable to help you when you need them most? We offer some advice on how to avoid phoning them in the first place...
It's Sod's Law at its finest. The chances are that you won't ever need technical support until you have something very important to do with a very tight deadline that could make or break your career in the music business. That, of course, is when things will all go wrong.
If we stop and think about this, perhaps it's not really that surprising. An important job may be that bit bigger than the kind of thing you'd normally undertake, and if it's a professional job, that means it will pay better (so you have more to lose) and the timescales will be shorter and more rigid, thereby creating the perfect conditions under which you'll have to rush something and will make a small but significant mistake.
In short, the chances are that you'll have one or more technical issues that will stop you in your tracks, or even trash your project altogether. If you're a professional in the field of music and audio, or even if — like most of us — you work in it for fun but take it very seriously, then you need to have a strategy for coping with technical hitches. A methodology that says "what I'm faced with here is no different from any other type of problem. I can solve it with an appropriate mix of common sense and logic".
The alternative is that you pick up the phone to your technical-support helpline, but I would contend that if you do that, you're already on a road to nowhere. After all, we all know how helpful, instructive and rewarding phoning software technical support lines can be, don't we?
I would suggest that there's more to getting yourself out of a mess than simply phoning tech-support lines, anyway — even if they all provided first-rate services. And this isn't just idle speculation. I used to work for a company that was rather like one of the big advertisers in SOS, but which sold video instead of music technology. And, believe me, that takes a lot of support — so much so, in fact, that the support department was found to be an uneconomical drain on the company. Before that, I was solely responsible for technical support on an American range of digital audio workstations in the UK and Europe. So I've done a fair bit of technical support in my time. And what I've noticed over the years is that it's not a encyclopaedic, up-to-the-minute knowledge of the latest software updates and drivers that sorts a problem out — although that can certainly help. More often than not, it's having a cool, calm, logical unemotional approach, starting with: "OK. Things aren't working. This is where I am. How did I get here, and how can I get to where I want to be — that is, working again?"
Of course, it's even better if you can avoid having problems that make you want to ring tech support in the first place, and that's what this article should help you to do. In my experience, most of the people who ring tech support don't need to, or, in the worst cases, are ringing the wrong people entirely.
It's worth considering this point first. Many people contact the tech-support departments of equipment companies because they have bought gear from that company and it doesn't work, and they therefore believe that the company is responsible for getting them up and running. Put like that, this belief may seem reasonable, and indeed, when you buy a computer, a software package, or a hardware add-on, the manufacturer and the reseller have a duty to ensure that they have sold you a working product. Nevertheless, in the world of computer-based systems, this apparently reasonable belief can be completely mistaken.
Imagine you buy a multi-channel audio interface card, install it in your computer, and it doesn't work. Your computer doesn't 'see' it — it's as if it wasn't there. Frustrated, you phone the reseller, complain that he's sent you a dud card, and are asked to send it back for testing. A few days later you get a phone call to say that there is nothing wrong with the card and that it is being returned to you under the terms of the warranty. Many people in situations like this assume at this point that the reseller must be lying, but of course it's perfectly possible that they can be telling the absolute truth, and that the problem lies with your computer.
You don't buy a car by telling the salesman that you want a Ford engine in a Renault body with Volkswagen suspension; but that is effectively exactly what most people do when they buy computers, and this makes it all the more likely that a hardware expansion card from yet another manufacturer will be incompatible with some aspect of your computer. You're less likely to have this kind of issue with Macs than PCs, because only one company — Apple — makes Macs. With PCs, it's quite surprising that they function at all, when you consider the number of possible variations in hardware and software, and yet, most of the time, they work just fine. I must admit that this is one of the reasons I like them!
Now, consider the non-functioning interface card again. The person or organisation that sold you the card can't be held responsible for the state of your computer; you might have built it yourself from parts you found in a skip. Even if you bought it from a reputable manufacturer, there's no guarantee that the (almost certainly unique) collection of parts that comprises your computer is going to work with that card.
To take a couple of real-world examples from my experience, something as simple (and apparently unrelated) as an unusual CD drive can scupper the installation of what seems to be a completely standard PCI card. I once delivered 12 identical workstations to a customer. The CD rewriters worked in nine of them and failed to make a single CD in the remaining three. The computers were built in the same batch, with identical components and with identical software installations from a master disk. Eventually, I discovered that the problem lay with the IDE drive cables. The PCs in question were built into large cases with a mixture of SCSI and IDE drives. The layout of the cases dictated that the IDE drives had to be mounted at a distance that turned out to be right on the limit of the acceptable cable length. Because the installation was so marginal, and the positioning of the cable was so critical, the slightest movement of a cable could make the difference between it working or not. The answer was to use a different kind of cable, optimised for longer cable runs.
The bottom line is that if you are installing a PCI card in your computer, or any other type of device for that matter, it is nearly always your responsibility to get it working, and although you may elicit sympathy from suppliers if it's not functioning properly, you may well find it difficult to force a refund.
Now, I don't want you to think that this kind of nonsense happens every time, and I certainly don't want to discourage you from buying products for your computer. If you do a bit of research before you buy, find out about known problems and incompatibilities from the manufacturer, and where possible, from other users of the product (Internet forums can be very useful in this regard), you can be reasonably sure that your new purchase will work. But you need to be aware that there is a small but significant chance that it won't.
One way you can minimise the risk and make the question of responsibility clearer is by finding a supplier who is prepared to work with you and support you. If you're feeling confident of your relationship with your supplier, you could try asking this question at the time of purchase: "Will you refund my money if the card doesn't work?". An alternative, potentially more acceptable question is: "Can I bring my computer in and try the card out here before I buy it?".
Whether or not the supplier agrees to either of these questions is entirely up to him. If you are buying an expensive product (something that costs over £500 in the UK, say), then you are more likely to get a positive response than if you are buying something costing £30, like a network card. If I were the supplier, and I reckoned I'd be making enough from the sale, what I'd agree to do would be to install the card in the computer on the understanding that if it worked, you'd buy it. But I'd also have to say that if it didn't work straight away, then I would expect to be paid to make it work. If it turned out after work had been done that there was something fundamentally incompatible about your computer, I would still expect to keep at least some of the money, on the grounds that it took engineering time to verify that your computer was unsuitable. Having to pay in this way might sound totally unreasonable to you, but then perhaps you've never considered the wafer-thin margins on which the average tech-support department operates — more on this later in this article.
If you're looking to buy an obscure, expensive product, or one that you know has 'issues', and if it's likely that you might need to dedicate one computer to the task performed by it, then you should probably be thinking about buying a complete system from your supplier, one that is pre-configured by them, with all the software and hardware already installed. Assuming you're confident of their ability to furnish you with what you need, this takes the reasoning expounded in the last couple of paragraphs to its logical conclusion. This way, the supplier will have to assume responsibility for it working correctly — but they're also more likely to want to do so in the first place, because you'll have spent more money with them. What's more, the supplier will know that the system was set up properly, it will be based on computer hardware that they have intimate knowledge of, and they will probably have set up several systems just like it. If it does go wrong, there will be no uncertainty about your right to go back to them for support. But perhaps best of all, the fact that the system has been put together in one place will make it much less likely to require a call to support in the first place!
If you are going to buy a complete system, by all means tell the supplier exactly what configuration you want, but you should also be prepared to take advice about what will work best, and that should include being told that you shouldn't go for the very latest specification. Your instinct may be to buy the fastest thing on the planet because you want it to last as long as possible, but in reality, fastest doesn't always — or even that often — mean best.
In the five years or so I was involved in supporting desktop-video systems, there were periods when most computers that went out to customers worked beautifully, and then there were times when nothing seemed to work. We never did pin down exact reasons for this wild variation in performance — the closest we got was being able to say that it was down to some indefinable variation in the motherboards and the video-capture cards we were installing. Whatever the specific cause, we found that certain motherboards worked like a dream, while others would always bite back.
As a result, at times we found ourselves recommending combinations of processor and motherboard that were virtually obsolete by the standards of the day. This may sound ludicrous, but put yourself in the position of an editor who has to deliver 26 half-hour programs to The Discovery Channel in six months. Would you rather have a setup that was older, but proven to be stable and trouble-free, or would you risk a next-generation system that might give you a 20-percent faster clock speed, but also had a tendency to corrupt your projects every other day? Most of the time, speed isn't everything. But stability is.
By the way, the idea of buying the fastest possible computer so that it will remain current for longer is silly, in my opinion. If you buy the fastest computer around today, you will probably have to pay an extra couple of hundred pounds for the privilege. In around two months, the next incrementally faster processor will be out, and the one you've bought will cost around two hundred pounds less. That means you've actually paid around 25 pounds a week for the period when your machine was the fastest. With this in mind, I normally buy machines that are as much as a year behind the leading-edge processors. Not only are they always half the price, but all the nasty issues with new processors (and especially with new chipsets) will have been ironed out.
We have all benefited from the plummeting price of the technology used in music production, but the hidden downside of this is that manufacturers and resellers make less money on each product that they sell, and therefore have smaller budgets for after-sales support. Let's look at some typical figures...
A support technician might earn something like £14,000 to £20,000 a year in the UK. Someone who earns £20,000 probably costs the company getting on for £30,000 a year after taking into account national insurance, heating, lighting, office space, and so on.
Now, support technicians don't actually earn the company any money. Although it's quite possible that they boost the turnover in the longer term by making customers feel better about the company, when it comes to assessing who brings the money in, a tech person will be way down the list.
So, if it costs £30,000 to pay one support person for a year, how much software does the company have to sell to cover their wages? This isn't an easy calculation, because even though the software might cost you, say, £300 from a shop, that doesn't all go to the shop. In fact, they'll make a fraction of that — 20 percent if they're lucky, and if they're in a price war with their competitors, they could make a quarter of that. So on a product that sells for £300, the shop could be making as little as £30, or even £15. Divide that £15 into the cost to the company of a tech-support person, and you get 2000, which is the number of software boxes the business would need to sell just to cover the person's wages — and nothing else. In reality, there's still the rest of the business to pay for: sales people, accounts and administration, demo stock, and so on. So the true number of sales needs to be three or four times the number needed to pay for technical support alone. And we haven't even started to talk about profits, and the likelihood (or unlikelihood) of making any!
Perhaps you can now understand why your software supplier either has no dedicated technical support, or has just a few people spread across a huge range of products. And it might be clearer why someone who has spent 40 thousand pounds on a professional system, who has lost contact with his hard drives and has a program to deliver to Channel 4 in the morning will probably be given priority over a user who 'doesn't seem to have his Cubase registration number to hand', and who actually wants to know how to adjust the height setting on his monitor.
- Buy a complete system. Tell the dealer exactly what you want the machine for, and then if it doesn't work, the dealer has to put it right.
- Do your research and take advice. Unless you'd rather spend your music-making time messing around swapping motherboards and different types of RAM.
- Test your workflow. Before you start work on a paying project, make sure you can actually accomplish what you've said you can do. If you've got a deadline to deliver a 5.1 DVD Audio remix, make sure you have the tools to do the job and that they actually work in your setup.
- Be methodical: was it working before? Have you changed anything that could have caused the current problem? If something was working and suddenly stopped, try to recall what you were doing at the time. Did it work until you installed some new software? Or a new I/O card? Have you just moved your computer? Or plugged in a Firewire, USB, or S/PDIF cable? You may laugh, but I've seen computers 'blue-screen' when I plugged in a simple S/PDIF cable; there was an external sync conflict that was badly handled by the I/O card driver. Apart from hard disks, hardware failures are quite rare. If your computer hangs irrespective of what you are doing at the time, suspect a heat-related failure. You'll probably find that the processor fan has seized up!
- Don't upgrade just before you start a new project (or, worse, in the middle of one). And never use beta software just because it's got the features you think you need for the next job.
- If you have a project that doesn't seem to work properly, try starting a new, simpler one. If that appears to work with newly created data, try importing the data from the old project into the newer one. If the old data stops the new project working, then the chances are that data is corrupt. If the old data works in the new project, then the old project may be corrupt, and you may be able to fix your problem by cutting and pasting the timeline from your old project into a new, blank one (alternatively, some software has a Merge option, in which case you need to merge the old project into the new one).
- Be prepared to stay working with a system that is supposedly 'out of date'. It may work better than a newer and supposedly faster system. Let someone else find the bugs and conflicts.
- Maybe the problem is outside your computer; check your cables. There's no point spending hours re-installing your software if the problem is with a cable. The more a fault seems to defy logic, the more likely it is to be a cable problem. You can save hours of frustration by eliminating cable problems from your investigations at an early stage.
- Don't fill your hard disks: leave at least 20 percent free. All kinds of bizarre things can happen when your hard disks fill up, to say nothing of the performance hit this causes.
- Finally, I have two simple words for you, but they're the most important ones in this article. Back up. Do it every time you've created something you'd hate to lose. If you're doing any kind of professional work, your data may be worth more than your computer itself. When you save a project, save it in several places, maybe to a second hard drive or even a removeable USB or Firewire one. Don't just overwrite the previously saved project — you may need to go back to it or an earlier one. If your project gets corrupted, then overwriting the earlier, valid project will leave you with nothing. Name your saved versions logically ('Project 1.1', 'Project 1.2', and so on). If you do this, then regardless of what data-protection routines are (or are not) built into your software, you have yourself the equivalent of an infinite, selective undo facility. Back these versions up to a CD-R. Make several copies. Keep one at a friend's house and one in your car. And understand how to back up projects properly from each type of software you use. A project file is no good without the data it has to refer to in order to work (for example audio samples, virtual-instrument settings, video clips and so on). Make sure that your backup routine includes data like this: project files, setup files, samples, sample mappings, and any other kind of data that you'd need to reconstruct if it went missing. Do a trial backup, and — backups are worse than useless without this — make sure you can restore from the backup. As far as is possible, don't use older storage formats that you suspect might not be around in a year or two, or which might not be supported next time you upgrade your OS. If your system ever has to be sent away for repair, you'll be glad you had a decent backup, because there is no guarantee that your data will be there when the computer comes back.
So — you've followed all the advice in this article, considered the slender margin on which the average tech-support department works, and you still think you need tech support. Well, don't give up yet. Before you make that call, try to put yourself in your supplier's position. What they are responsible for is selling you a working product. What they are definitely not responsible for is getting your project finished before a deadline that you have agreed with your client! Have you actually read the manuals that come with your systems? And don't just dismiss this comment — I've come across lot of people who are "too busy to read the manuals". In the most outrageous case I encountered, someone once called me to say, "I've just unpacked my machine, and I'm starting an important project for the BBC... I want you to stay on the phone while I do it"!
In a similar fashion, some people turn up unannounced at the tech-support departments of large companies with their computer in their arms (be it laptop or desktop), hoping to get it fixed before they leave. The simple fact is that most companies don't have enough engineers with time on their hands to be available for drop-in customers. Some of the more obscure problems (inevitably caused by software and hardware conflicts) can take ages to track down — as much as a whole working day. Would you expect to get your car serviced without an appointment? To do so is unfair.
If you do phone, it's a good idea, at the very least, to have made notes about your system configuration, and anything you might have done that could have triggered the problem. You might even find that the process of putting these notes together makes you think of something else you can try yourself. If you do your research, are methodical and don't panic, you can avoid all sorts of problems. If you do run aground in the middle of a project, think about it (and the circumstances surrounding it) logically, and the chances are that you can fix it yourself, avoid wasting hours on the phone — and win a rare victory over Sod's Law into the bargain!
Thanks to Mike Fletcher and his on-line history of telephony at www.telephonesuk.co.uk for the pictures of vintage phones used in this article.