Ethan's Top Ten List of Stupid Programmer
Tricks You Should Avoid

by Ethan Winer

(This article first appeared in the December 1997 issue of Visual Basic Programmers Journal.)

It's easy for programmers to view people who use their software as incompetent boobs who don't know the difference between a disk directory and a RAM chip. Indeed, we've all heard stories about the tech support caller who folded his 5-1/4 inch disk to stuff it into a 3-1/2 inch slot. Or the poor sap who didn't understand that a monitor won't work until it's plugged into the wall outlet. Or the caller who wanted to order a replacement for his computer's broken "cup holder" (CD-ROM drive). True or not, these stories surely don't represent most users today. As an avid Windows user, I am insulted daily by programs for which I paid good money. Following are the ten most obnoxious things programmers do that alienate the very people who bought their programs.

10. Please don't waste my time with "Are you sure?" dialogs, unless I try to quit your program without saving or I'm about to overwrite a file with the same name.

9. If your program has a "live update" option to download new program and data files, please confirm that I did not select it by mistake. Don't just launch my browser and start dialing!

8. During installation, never steal an existing file association without asking. Just because your program has an option to, say, view .GIF files, don't assume I plan to replace my existing viewer with yours. And never overwrite an existing program or data file without first confirming it with me, unless you are absolutely sure the original is an older version of the same product.

7. If your program needs a few moments to complete something, be sure to show an hourglass. Likewise, progress indicators let us know your program hasn't gone out to lunch. A display such as "Processing record ## of ####" is always better than leaving us to wonder if it's time to reboot. And always provide a Cancel button, in case I selected "Print entire database" by mistake.

6. Unless your program truly needs to put files in another directory, such as C:\WINDOWS\SYSTEM, keep everything in one place so I can uninstall manually if necessary. This program may represent your life's work, but to me it is just another tool that I may or may not decide to use. And if you really do have to spray files all over the place, take 20 minutes and write up what went where in a README or Help file.

5. Speaking of Help files, please don't clutter up my hard disk with screwball manual readers, or worse, yet another movie player. The Windows Help system is very capable, thank you, and everybody already has it. Further, make sure that every menu item and dialog choice is indexed in Help so I can find it quickly, and provide a link from every dialog option to the appropriate place in your Help file. It doesn't matter whether you include a Help button on the dialog box or use the newer "What's this?" method. But please let me find everything I need while the dialog is showing so I don't have to write down a caption, close the dialog, and look it up in Help manually.

4. Identify all of the data files that your program creates. Nothing is more frustrating to an experienced user than not knowing what files must be backed up. Sure, I can check the dates and Archive attributes for every file in that directory, but why should I have to? You already know, and all I ask is that you tell me. Further, do not hard-code the path to your data files. Either give me a way to specify the path, or honor the Windows Properties Shortcut's starting directory. I rely on this, keeping all my programs on drive C: and all data files in parallel directories on drive D: to simplify backing up.

3. Have someone - anyone but another programmer - review your documentation to be sure it is complete and, more important, understandable. And please check your spelling. Few things will undermine my confidence in a program more than obvious spelling and grammar errors. If you can't get that right, why should I believe you paid any more attention to the actual coding?

2. Always save window sizes and locations automatically when the program ends. Better yet, let me set everything the way I want and choose "Save Preferences" from a menu. If I decide to move something just for this session, all will be restored the next time I run it.

1. And finally, the Number One stupid thing you can do to guarantee your users will hate you (Anton, drum roll please): Don't insult us with copy protection. If you offer a useful product at a fair price, I promise it will be a success.

Entire contents of this web site Copyright © 1997- by Ethan Winer. All rights reserved.