by Lloyd Borrett
Today's Computers, PC Australia, August 1985
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
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.
Saturday, 15 October 2011