Risky Business

by Lloyd Borrett
Today's Computers, PC Australia, August 1985

Lloyd Borrett

How many spreadsheet solutions have you developed? Are you happy with them'? Are you sure the results they produce are correct? Of course, you would gladly swap solutions with anyone else because they surely take the same precautions you do. After all, everyone carefully checks their spreadsheet solutions, documents the method used, and records all changes made. You do all that, don't you?

The acceptance of personal computers in business has been largely due to the benefits gained by using spreadsheet programs. VisiCalc, Lotus 1-2-3 and other spreadsheet programs allow executives to bang out models and forecasts simply and quickly. But how many have stopped and considered the potential for errors?

Dan Bricklin, chairman of Software Arts, was one of the two designers of VisiCalc, the spreadsheet program that started it all. "Just as dial telephones turned us all into telephone operators, VisiCalc turned businessmen into computer programmers," he says.

What? A spreadsheet solution is a programming language? And businessmen are computer programmers'? Yes indeed. If you have been using a spreadsheet program, then you have been doing computer programming.

With literally thousands of programming languages available today, computer scientists have established criteria for what makes a good programming language and what makes a bad one. By any of these criteria, the spreadsheet is a poor programming language.

The real danger is that the new breed of non-technical users of personal computers does not even seem to be aware of this. When a problem is being solved with a spreadsheet program, most pay less attention to checking than they would if solving the problem by hand. Spreadsheet users often ignore even such standard accounting procedures as "hash-totalling" — adding up all the figures across a spreadsheet row to see if they agree with vertical column totals.

Most spreadsheet solutions produced by the typical business user are classic examples of everything that could be wrong with a computer program. The code is difficult to understand. How do you know that reference to cell E15 shouldn't be W15? Maybe that plus sign should be a minus sign. Who knows?

That is the problem; in most cases no one does. Studies have shown that poor programming languages are far more "error prone" than good ones. The probability of a programming error in a spreadsheet solution is perhaps a hundred times as great as it would be if the same solution were written using a structured programming language.

Even if you have checked the spreadsheet results, the chances are that your solution isn't documented properly. Sure, you can understand it all now — but what about in six months? God help the company if you should leave, or get run over by a bus.

When you create a spreadsheet for your own use to help balance the cheque book, for example — it is one thing. But more and more financial models stored on a company's disks are shared among many users, and a single mistake may affect decisions made in many different sections of the company.

The reason all those data processing department backlogs exist is because professional programmers spend most of their time designing the solution, building in safeguards, documenting the methods used, and testing the result.

Yes, you can jump the queue by becoming a programmer and using a spreadsheet program to produce a solution. But think for a moment about the problems you would expect if the data processing boffins were to start doing your job. Should it not be the same now that you are undertaking to do their job'?

Lloyd Borrett is support co-ordinator for HiSoft Australia, President of the Australian PC User Association, founder of the Melbourne PC User Group, and system operator of the PC Connection bulletin board.

[ Top ]