Channels ▼
RSS

Keep It Simple


Java Solutions April 2002/Editor's Forum

Editor's Forum


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


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.