Keep It Simple

I recently wrote an article for JavaWorld in which I discuss the tools that I use for OO design (a whiteboard, a digital camera, a simple text editor, and CVS for version control). I’ve designed significant projects with nothing more than these four tools and strongly believe that this simplicity makes the whole process go much more smoothly than if you were using an OO CASE tool. (The article is at <www.javaworld.com/javaworld/jw-01-2002/jw-0111-ootools.html>, if you’re interested.)

The point of mentioning this article is that the reader feedback was surprising to me: only one of the couple dozen people who chose to write was a fan of the CASE tools. Contrast this implied opinion in favor of the simple approach with the common wisdom that a CASE tool is just about mandatory for any real design work, and a certain cognitive dissonance emerges. The fact is that the fancy tools are simply unnecessary, and that the simpler the work environment, the easier the work.

I actually take my notion of simple tools even further. My Java development environment borders on primitive: VIM (from <www.vim.org>) as an editor, the command-line compiler from Sun, documentation in the browser, and that’s it. No visual debugger, no drag-and-drop UI tools. The shockers, here, are probably the last two, so let’s talk about those. Years ago, now, I read Fagan’s now classic articles on formal code inspection, and these articles changed the way that I work in fundamental ways. The core idea of a code inspection (or a less formal “walk through”) is that you can find more bugs faster simply by closely reading the code than you can by using a visual debugger. My experience proves this idea; at least I’m spending vastly less time debugging than I used to, and my code is more robust out of the gate.

Rather than use a debugger, I print the listing and then go over it with a fine-tooth comb.
(I recommend using paper listings and getting away from the computer for this purpose, since the change of environment seems to help me see things more clearly.) I usually find oodles of bugs, which I fix; then I print another listing and repeat the process until I can’t find anything wrong. If I’m working in a team, I’ll then give the listing to a co-worker and ask them to go over it, too.

This manual process is stunningly effective, I think, because you tend to see the code in a global way when you’re reading it, while in a debugger you tend to focus on a single flow of control. If you don’t believe me, try it.

The second surprise I mentioned was not using a drag-and-drop layout tool. I’ve several reasons for not using these tools. First, my approach to UI is strongly object oriented. (You can read about it in the “Building User Interfaces for Object-Oriented Systems” section of the “Articles” page on <www.holub.com>. I also recommend Larry Constantine and Lucy Lockwood’s book Software for Use.) One of the things implied by a strong OO bias is that get/set methods are evil, since they expose too much of the implementation of the object. Since all of the drag-and-drop UI builders are based on using get/set methods, I consider the resulting code to be both too procedural and too low quality for a production system. I also find the drag-and-drop approach to be a poor fit for AWT/Swing, which takes a dynamic run-time approach to layout. The UI layout might (in fact, should) change with factors like screen resolution and real estate available.

So, I recommend that on your next project, you experiment a bit and ignore the common wisdom that automated tools improve productivity. Sometimes the simplest approaches really are the best.

Allen Holub
Senior Editor