35.1. On Speculative Design and Visual Thinking

The designs illustrated in UML diagrams will be incomplete, and only serve as a “springboard” to the programming. Too much diagramming before programming leads to time wasted in speculative design directions, or time wasted fussing with UML tools. There's nothing like real code to tell you what works. Bertrand Meyer said it best: “Bubbles don't crash.”

Nevertheless, I vigorously encourage some forethought through diagramming before programming, and know it can add value, especially to explore the major design strategies. The interesting question is “How much diagramming before programming?” In part, the answer is a function of the experience and cognitive style of the designers.

Some people are very spatial/visual thinkers, and expressing their software design thoughts in a visual language complements their nature; others aren't. A large percentage of the brain is dedicated to visual or iconic thinking and processing, rather than textual processing (code). Visual languages such as the UML play to a natural mental strength of most people. Those educated in the UML obviously have an easier time at it than those who are not. And in general, more experienced object designers can effectively design by drawing without straying into unrealistic speculation, because of their experience and judgment. Applied by adepts, diagrams can help a group move more quickly toward a skillful design, due to the ability to ignore details and focus on the big picture.

One exception to this “light” diagramming suggestion is systems that are naturally modeled as state machines. There are some CASE tools that can do an impressive job at full code generation based on detailed UML statecharts for all the classes. But not all domains naturally fit a strong statemodel-centric approach; as examples, machine control and telecommunications often fit well, business information systems often don't.