WHAT MAKES A GOOD PROGRAM?

Surveying the many programs available for Adam, or any other computer for that matter, often begs a question.

What makes a good program?

How often have you paid good money for a piece of software that disappoints you or that you felt was overpriced? Or perhaps you've written a program or two yourself, left them for a while, and returned sometime later to find your masterpiece is not nearly as brilliant as you'd first considered it to be.

The truth is, there's no single easy answer to the question. It may well be that one group of target users will criticize software that has completely pleased another. The variance of preferences can be infinite, but there are some general rules.

One author, Edward Yourdon, sums up his view of a good program this way:

- It works.
- It works according to specifications.
- It is ready on time.
- It has no bugs.
- It is flexible
- The bugs, which are inevitable, can be fixed quickly.
- It is well documented.
- It executes quickly.
- It makes efficient use of memory.

A few pages later, the author has elaborated on this criteria somewhat, and throws in another rather interesting set of criteria which he calls "devious, perverse, illegal and immoral programming practices.

- badly commented or uncommented code.
- use of assembly language when a high level language will do as well.
- misuse of (language) instructions.
- programs that modify themselves.
- sharing temporary memory storage and variables amongst several subroutines.
- excessive use of macros
- excessive use of "goto's".
- non-nmemonic variable names

Much is written about knowing exactly who you're writing for. One rather interesting charactization of so-called 'professionals' reads as follows:

- They know little about computers.
- They are not interested in knowing about computers
- in fact, they may not even like them.
- They know how to turn the computer on.
- They (probably) know how to load the program and bring up the first menu.
- They have probably not read any program documentation.
- They cannot be expected to remember anything that is not presented within the context of the program.
- They will consistently ignore screen prompts, and will enter data that have inappropriate type, format, length, and other characteristics.
- They are motivated to accomplish the function the program was designed to serve.
- They resent it when things go wrong and will blame it on you.
- They will write data to the program disk, if possible.
- They will attempt to load data from an empty disk drive.

Take that for what it's worth. The same author, Henry Simpson, actually provides a definition of user friendliness:

"....a "user friendly" program is one with features that acknowledge human factors.....ie. the various characteristics of people which influence their performance - memory, ability to see and hear, motivation, motor skills, and so on."

"In general, a user-friendly program is easy to use, tolerant of operator errors, easy to learn, and acknowledges that human beings are imperfect creatures."

Let's deal with some other features.

As a user, you might have a preference for menus. You want the program purpose to be stated 'up-front', and you want full guidance as to how you'll reach your destination - the job to be done. The opening screen should present you with a series of choices, clearly and concisely stated in an opening format that is both readable and pleasing to the eye. At this point, choices should be selectable with a single keystroke, or at the very most, a single word. Depending on the complexity of the program, there may be branches at this stage to other menus.

Opening instructions displayed on the screen should state in a concise manner the purpose of the program and the essential things that the user needs to know in order to operate the program. It is not likely, as we have seen, that the average user will be willing to refer to documentation, so don't assume that the book has been read. Provide a few well worded hints to prompt the user from the beginning.

There should be a method of bypassing the initial instructions once the user has become accustomed to the program. Menus can be shortened to provide only essential prompting and the more routine program functions can become automatic. The SmartWRITER program has been criticized in this regard for being almost too user friendly. The persistent question "Are you sure?" can become a source of annoyance to those who know exactly how the "delete" key functions.

The average user expects a certain amount of forgiveness in the area of command or data entry. Some programs will simply return you to the beginning when incorrect data formats or commands are entered. Others seem to be endlessly patient. Suffice it to say that the user should have at least one chance to foul things up without crashing the program. After that, a certain amount of assistance should be available in the form of a 'help' command. It follows then, that the program should be capable of error checking to some degree.

In the matter of colour and fancy screen layouts, preferences are so diverse that it is difficult to state any hard and fast rules. Some prefer a plain black screen with standard white letters; others may be using a monochrome monitor and will want colours that show up well on it. Others may expect all the colours, flashing, and other bells and whistles that the computer is capable of, and be willing to sit through whatever form of entertainment display the programmer cares to provide. The answer would seem to lie in making your program as flexible as possible. Provide choices.

Screen layouts are important. Some Adam programs sacrifice clarity and readability by cramming too much information onto the screen at once. Others provide so little information that the user has difficulty following. Flashing data can be distracting and hard on the eyes. In some cases, there is little distinction between one section or screen of the program and the next. These are all aspects which require careful consideration.

Documentation is another important area. There should be sufficient information provided in a .doc file or in written form to permit the user to learn how to use the program, and what to do if something doesn't go quite as expected. We'll be reviewing the characteristics of good documentation in a future article.

REFERENCES:

Design of User-Friendly Programs for Small Computers. Henry Simpson - McGraw Hill, l985.

Techniques of Program Structure and Design. Edward Yourdon - Prentice Hall, 1975.