I certainly agree with many of the points in the article and with your admonition regarding the separation of business rules from presentation or data abstraction code.

I would caution folks to read the article carefully and to remember when it was written. (In 1991, Windows was just starting to become firmly entrenched in the business world and the Internet was used very differently than it is today.)

I would also be interested in knowing what Tom would amend, if anything, to his thoughts today. I know I held certain rather strong opinions ten years ago, thoughts I'm a little more flexible with today.

In any event, I would rather folks read this as a reminder to design their applications carefully, separating various elements as appropriate, e.g. MVC.

Like them or not, GUI's are a part of the modern application development process. And while I don't think every application should be a GUI, I also think the reverse is true: not every application can (or should) attempt to executed from a command-line.¹

There's a balancing act involved and far too many programmers ignore the flexibility of command-line approaches. Indeed, there are many ways you can use the command-line to make your applications more flexible. For example, The Pragmatic Programmer recommends adding command-line support for testing your derived results, which can save countless hours of manual testing effort.

In any event, I believe that the best programmers create highly organized applications using good practices, such as the MVC model. I believe they also create applications appropriate for the conditions they're commissioned under. For example, a client willing to pay for a 40 hour job will likely get different results than the client paying for an 80 hour job--unless the 80-hour job can be built in 40 hours. So, it's important to consider all factors before making design decisions--and that's my real point. You should know what you're going to do and why you're doing it before you start pounding out code.²

(Along the same lines, I also believe that you should also give yourself a break. You will make good decisions and you'll make bad ones. That's part of the process. Learn from the mistakes and take time to run a personal post-mortem on your part of a project. What could you have done differently? What worked? What didn't? Once you have that, devise and incoporporate strategies for avoiding the mistakes in the future.)

I do agree that many people who design GUI applications take far too many shortcuts and ignore the potential needs of users other than the ones interviewed by the business analyst. And that's dangerous. It can also limit your access to certain markets. For example, the U.S. Government now requires accessibilty³ to be built into all applications developed by sub-contractors. If you can't do that, you can't bid on those contracts.

If you create GUI's, then make certain that every rodent-triggered event can also be triggered with the keyboard. For best results, let the user assign the hot-keys, the accelerators, and so on. That way, you can let the user configure the program for their way of working.

If you're interested in reading a good, thought-provoking book on GUI design considerations, I highly recommend Alan Cooper's About Face. It's a little dated now, but it still raises some important points worthy of consideration.

In any event, the real lesson from all of this is to separate content from presentation (You're all doing this in your web pages, right? Yeah, that's what I thought) and to make the decisions appropriate for the project at hand.

--f

¹ I think very few applications fall into the latter category.

² For those looking for things to work on, this might an area to explore. We have gained a tremendous number of tools for building various applications with Perl and with other languages, but the process is still very labor intensive. It would be really nice, for example, to see tools appear that automate the tedious stuff. There is, after all, more than one way to do things.

³ The site that link points to is geared toward web accessibility, but the anchor points to the actual standards. Since I believe it's useful for folks to understand both issues, I chose the first link. Hope you understand.