GUIs considered harmful

It's tempting to create a solution that uses a GUI program. Most people are comfortable with GUI programs and uncomfortable with command-line programs, so they prefer the GUI solution.

The problem with GUI programs (most GUI programs) is that they are not automatable. You cannot drive them to perform a task. GUi programs cannot be (easily) plugged in to other programs. The GUI is the end of the line, designed to be used by a human and nothing else.

The ability to use a program within a larger system is a good thing. We're not omniscient. When designing a program (and thereby automating certain tasks), but we also choose to leave some tasks to the human in from of the GUI.

For example, the task of deleting files (in Windows) can be performed in the Windows Explorer program, a GUI program. I can select a set of files, or a directory name, and instruct Windows Explorer to delete those files. For normal files, Windows Explorer performs the task with no other action from me. but if any of the files are write-locked (that is, flagged as read-only), Windows Explorer will ask me about each file before deleting it.

The folks at Microsoft added a button to the "are you sure about this read-only" file to tell Windows Explorer that I was sure, and that I was also sure about other files marked as write-locked. But this is an after-the-fact behavior, and only comes into play after the first write-locked file has been encountered. (Also, there is no way to tell Windows Explorer in advance that I want this behavior. If one of the files is write-locked, Windows Explorer will trip over the first one.)

The command-line command in Windows to delete files (DEL) on the other hand has options that can remove write-locked files, and you specify them in advance. With one action, you can tell the command-line shell that you are serious about deleting files and don't ask you any silly questions.

Command-line programs can often be used within larger systems. In Windows (and MS-DOS), one can use batch files to execute a series of programs. Unix and Linux have similar (although more powerful) concepts with their shell programs. And all of the major operating systems support redirection to accept input from a file instead of a keyboard.

Not all GUI programs are evil. Microsoft has done a rather good job of usable GUI programs. Their programs are often designed with two layers, a Gui layer and a lower layer that can be used by other programs. Sometimes this layer is a command line, sometimes it is a COM interface. But the work has to be done, the design has to allow for "bimodal" use.

It's all too easy to design a GUI program for the moment, implement it, and lock out any future increases in automated capabilities. A GUI program prevents others from automating tasks and often freezes the developer at a specific level of automation. A developer of a GUI program is in a comfortable position, with some (perhaps most) of the work being automated, and an expensive proposition for additional automation (changing or re-writing the GUI program). Once in this position, the developer ceases to think about improvements to the program -- the program is "good enough" and the developer convinces himself that the remaining work isn't that onerous. This is not a good place to be.

I don't advocate the elimination of GUI programs. They can be effective. But they can also lead to a stifled mental state.