Seeing that his ruse is discovered, the man speaks these final Wizardly words into the mike: “Pay no attention to that man behind the curtain!”

Alas, the jig is up for the Wizard, and our heroes and heroine have been duped, but the story doesnt end there. Instead, the nice old lever-puller dispenses some tired aphorisms that seem to satisfy everyone except Dorothy, who will still need a “good” witch and some magic shoes to make her trip home.

Heres what I could never understand, though. How did the Wizard get away with that, uh, bullstuff? Personally, I was waiting for the Tin Man to teach him a hard lesson with the butt end of that axeor maybe for the Cowardly Lion to rip a nice chunk out of the old shysters keester. But no, our battlers not only walk away without anger, they actually like and respect this loveable fraud, despite the fact that he has put repeatedly put their lives in danger.

And you know, its a bit like that with software companies, too.

We recently reported that a Department of Commerce study found that software bugserrors in programming that are part of just about every software application out thereare costing U.S. businesses nearly $60 billion annually.

According to the authors of that report, software buyers are simply willing to put up with more “errors” than, say, automobile buyers would be. Every year, vendors produce, and companies buy, software products that will have bugs, but everyone seems to take that in stride. Why is that? How do software vendors get away with that bullstuff?

First, its important to realize that when you buy software you are actually buying millions of lines of computer programming, known to the tech community as “code.” This code contains millions of instructions that are given to your computer and peripherals to produce what you experience as a functioning program.

Code, of course, is highly technical and not easy to write. Thats why, even in this quiescent economy, skilled programmers can still make a very good living.

In any case, if a programmer slips up on writing a few lines of code here and there, you probably think thats not so bad. After all, you reason, nobodys perfect.

The problem is that while many of these slipups are harmless, some of them have the potential to affect not only the functionality of the program in use, but the viability of other programs, and even of your entire operating system. Such errorsthose that result in systems shutdown, loss of data, or need for significant systems reconfigurationare heavily implicated in the billions of dollars in losses cited by the Department of Commerce study.

Its not unreasonable to expect some imperfections in a product, especially one as intricate as software. Its also not unreasonable, however, to expect that software makers will at least protect us against the most egregious errors in their products. Unfortunately, that sometimes doesnt happen.

Why do we accept this? Why dont we demand that software makers do better and more extensive testing of their products?

Part of the answer, I believe, lies in the fact that we want what the software claims to offer usso much so that were willing to roll the dice and pray the result isnt Snake Eyes. Software, and technology in general, is often so whiz-bang exciting that the thrill of beating the odds overcomes any cautious thoughts we might have about dangerous bugs.

And lets face it, most of the time we dont roll Snake Eyes and our software investment, even if it needs a little tinkering, gives us at least some of what we want.

But what do we do when both dice show a single dot? If the software vendor wont make good, surely we have legal recourse, you say. If you believe that, then the Wizard would love you.

Just take a peek at the licensing agreement of any software product to get an idea of just how few rights, if any, you have with regard to that products failure. But then, nobody reads those agreements, and software makers count on that.

So, how can you possibly fight city hall, along with your own needs and desires for cool software? Here are a few suggestions:

If youre buying software off the shelf, dont buy an early version of anything. One of the ways software makers find bugs is by listening to consumer complaints. Let them listen and fix the worst bugs before you lay your money down.

Pre-test any software (You can often find free demos or versions that are good for a limited time) with the kinds of work you need it to do. Take advantage of these versionsand of money-back guaranteesto put potential programs to the test.

If youre buying a large-ticket software application that requires customization in your operation, make certain you understand the warrantees and guarantees the software maker offers. Then have your own IT people, or a hired gun, watch and evaluate the customization closely. If implementation time is an issue, tie successful completion to completion of payment.

Make a strong pot of coffee and take the time to read the licensing agreement that comes with any software you are seriously considering. If anything there bothers you, look to a competitor.

Do as little tinkering as possible. While its reasonable to think youll have to modify customized software to fit your work processes, carefully evaluate the amount of changing youll need to do. More tinkering means more potential problems.

These tips should help you make a better software decision, but the pervasiveness of software errors isnt likely to abate. Your best defense is to be a stickler for detail and to refuse to buy on impulse.

Otherwise, the best advice I can give you is to find a pair of glitter-covered womens shoes (sorry, guys) and click the heels together three times while chanting, “Theres no place like home, theres no place like home”

Senior Editor Ara C. Trembly is NU's tech guru. He can be reached at [email protected].

Reproduced from National Underwriter Property & Casualty/Risk & Benefits Management Edition, September 16, 2002. Copyright 2002 by The National Underwriter Company in the serial publication. All rights reserved.Copyright in this article as an independent work may be held by the author.