FOOTNOTES

The Laws of Computing

by Karl E. Wiegers

Karl E. Wiegers pays heed not only to the aforementioned 13 laws, but also to the 14th law, which he forgot to mention: All regular ST-LOG contributors are popular with members of the opposite sex, are invited to lots of parties, don't have to eat quiche and are secure in the knowledge that their words are being read by the most intelligent readership in the industry.

For 17 years, my fingers have caressed the keyboards of many computers. Ataris, Apples, IBMs, Compaqs, Control Datas and others have wrestled with me for control of the console. Sometimes I won, sometimes I lost. I win more now than I used to. In part, this is because I have become aware of certain immutable laws that govern the interactions of men and electronic machines.

I've formulated these principles as concisely as I can into Wiegers's Laws of Computing. No doubt there are others, but I haven't discovered them yet. Today I'd like to share these laws with you, in the hope that you, too, will win a bigger fraction of the console battles.

First law: Almost nothing you can do with a computer is difficult.

The novice laughs in disbelief when he reads this law. But it's true! Every computer program is just a sequence of short statements, most of which are easily understood by even a beginning programmer. And as a user, almost all commands you issue to the computer are simple, containing just a few words, and maybe punctuation, but you might not need the right parenthesis, and blanks, which may or may not be important, and quotation marks, which may have to be single or double. Sometimes you have to type in uppercase, but sometimes the computer doesn't care.

Now, none of these details results in a particularly difficult interaction. The hard part is remembering the precise format of each command. How do I erase a file: ERASE, DISCARD, PURGE, DELETE, KILL, FLUSH? Can I abbreviate the keyword? To how many letters? Or do I select a letter (D, maybe) from a menu? Or do I click on the file and drag it somewhere? The real goal is to avoid the computer responses that make our blood run cold: "Syntax Error," "No Such Command," "File Not Found."

You see, the difficult part is not issuing a command to the computer; it's remembering which command to use and how to use it—which leads to the next law.

Second law: Almost nothing you can do with a computer is obvious.

Once you've seen the second law, you're more likely to believe the first. The diversity of incompatible computing machinery and operating systems means that we must remember an inordinate amount of trivia to get our work done. I spend time these days on an Atari 1040ST, Atari 130XE, Apple IIe, Macintosh II, Compaq 286 and IBM 3090 (a huge mainframe). This means I have to remember how to use six different operating systems, besides a ridiculous number of text editors.

The information I need for all these computers is not intuitively obvious. So in the absence of standard systems and online help, how am I supposed to keep all this stuff straight? With the aid of manuals, of course.

Third law: The existence of manuals does not violate the second law.

Naturally, this assumes that there are manuals, which is debatable for the Atari line But the vast majority of manuals only pretend to help you remember the keystrokes you need to escape from your computer session alive. It's all in there somewhere (maybe), but I'll be hanged if I can find it when I need it.

I remember a time when the horizontal surfaces in one's office held things like pictures of the family. Now every square inch is filled with computer manuals, many still in the shrink wrap. Sometimes it's faster just to try all the commands you can think of, instead of digging out a manual and hunting for the answer.

But I have a theory about this. I think computer and software manufacturers deliberately write inadequate manuals, thereby creating a huge aftermarket for magazines, books, courses, keyboard templates, training videotapes and tutorial disks. And who writes all this stuff? Why, the wizards of course.

Fourth law: If you are one week ahead of the other guy, you are a wizard.

This is one of the social phenomena of the computer age. In more mature fields like woodworking, it takes years of experience to become an expert. But the rate of appearance of new computer information is so high that if you have just a little head start over the other guy, you look like a magician. Therefore you can be of great help to more primitive users who bought their computers the week after you did; you've carved a niche for yourself. The challenge for the wizards is to keep that one-week lead.

Fifth law: If it is not in my computer and running, it does not exist.

This law refers to the peculiar product category known as "vaporware." I'm sure you've seen ads or announcements for products that never quite seem to make it onto the dealer's shelf. Atari is notorious for producing both hard and soft vaporware. I always quote this law when someone tells me about the next release of Superword or how much easier life will be when UltraMenu arrives. Ha! It's safest to assume that something is totally imaginary until you have it in your hot, grubby hands.

Sixth law: All programs are metastable. "Met-a-sta-ble, adj. Designating a relatively unstable, transient, but significant state of a chemical or physical system…" (The American Heritage Dictionary.)

If something is metastable, a small perturbation can destroy it. A house of cards is metastable. Peace in the Middle East is metastable. And all you programmers know that if you tweak a program just a little, the whole computer might lock up. You won't even know what you did wrong lots of the time. See my ST-LOG series on software engineering for ways to violate this law.

Seventh law: Artificial intelligence is no substitute for the real thing.

People try to violate this law more than any other. There are times you need to rely on your own memory or good sense, rather than asking the computer to do the thinking for you. Users sometimes expect ridiculous sophistication from a program in the area of error checking, suggesting that they think the computer is smarter than they are. Faster, yes; smarter, no. The cerebrum is still the best piece of software we've got, folks.

Eighth law: The fixing of one bug generates at least two new latent bugs.

Again, you programmers will know what I'm talking about. The problem with the latent bugs is that they don't show up right away so you can squash 'em (that's what "latent" means). Of course, users are notoriously good at revealing latent bugs and loudly announcing them, which is why programmers in large companies always request (but never get) unlisted offices.

Ninth law: Once you have trapped for all conceivable errors, the users become more creative.

We software developers really do try to anticipate and handle all the things that might go wrong when a user runs our programs. But how seriously can I take someone who complains, if he leans his elbow on the keyboard when he starts my program, his disk drive explodes? Refer such users to the seventh law.

Tenth law: The current backup copy of any file is always one generation too old.

This, of course, assumes that you keep backup copies of important files. Naturally, you don't make them as often as you intend to. Hence, when the inevitable catastrophe takes place, the warm fuzzy feeling you get from knowing you have a backup disappears when you find the backup disk covered with cobwebs.

Eleventh law: User manuals are consulted only after all possible keystroke combinations have failed.

This is really a corollary (no, not a Toyota; look it up) to the Third Law. To be sure, some of the better manuals do contain the information you seek, but we seem to insist on trying everything before reading the instructions.

Twelfth law: An undocumented feature is the moral equivalent of a bug.

Every once in a while you'll accidentally encounter something extra in a program, a feature that isn't in the manual but is nice to have available. Why isn't it in the manual? Who knows. Although such discoveries are pleasant (if rare), I classify them along with bugs (which are unpleasant and all too common) from a philosophical perspective.

Thirteenth law: Software version upgrades generally aren't.

Perhaps this is mainly a phenomenon of the mainframe world, but I doubt it. All too often, a new version of an operating system or compiler results in your programs running more slowly and needing more memory. Sometimes existing programs won't even run any more. Sure, the software has more bells and whistles (which you'll probably never use), but it's rarely worth the aggravation. Bug fixes constitute a violation of this law, but remember the eighth law.

As I said, I'm sure there are other laws that haven't dropped into my lap yet, but I imagine they'll be along shortly. If you keep these fundamental principles in mind, maybe you'll have a bigger edge over the machine next time.