Big Pictures

Is a picture worth a thousand words? Is a good picture worth paragraphs upon paragraphs of dry technical descriptions?

I am in the early DesignPhase of a large complex budgeting system: Different key users view their budgeting process in different ways; they share subsets of data and they often interact collaboratively.

I was recently reading JimCoplien's CppReport article "Worth A Thousand Words" (http://www.bell-labs.com/~cope/Patterns/C++Report/SpaceII-1.html). I consumed it hungrily, so I know that I am missing nuances (plus, I haven't fully digested the meal yet..), but I want to riff off of Alexander's idea regarding the importance of sketches in patterns.

For large systems, we need ways to communicate to the user as well as future developers the essence of the system. UML, OMT, Booch, etc just doesn't cut it. They aren't compressed enough: A good sketch should be a compression, not an abstraction or skeleton. I want those rare pictures that convey multiple levels of detail. I want PicturesAsCompression.

I believe that such sketches come in (at least for my purposes) two varieties:

The business domain model
The specification/implementation model

The business domain model is used to communicate to both the developers and users an overall understanding of the application domain. UML is either too precise, too abstract or too wrapped up in syntax to work effectively. (Recently, the users couldn't figure out if we understood their domain well enough... the UML, and the text, didn't convey that to them. They didn't get it. Drawing expressively on a whiteboard helped a lot. But, how do you capture that?)

The specification/implementation model is used to show how the system (implementation) is structured. How do the objects distribute? How do I convey dynamic distribution through serialization? Reading code is not the best start. Drop me in the middle of (even well factored) source code for a distributed system and I get lost. Give me a pictorial view of the terrain and then drop me...

I want to draw BigPictures. Yeah, I probably want something close to a holy grail, but I still strive for it.

-- ToddCoram

The Z people argue that mathematics can express and clarify many of the same things that pictures do, with the bonus that they can be reasoned with.

I sometimes find the value is in drawing the thing rather than in showing it to others. -- DaveHarris

Yeah. Just do it. I often reason in terms of shapes and spatial things. If I'm at an informal meeting and there is a whiteboard, I'll often draw shapes and connections, and label them to think aloud. Riffing off of DaveHarris here, I'll say that often the visual intuition is more correct than one would think on first pass. It is only after coming back to a picture a few times, that I realize how appropriate it is for making more points than those I originally ascribed to it. -- MichaelFeathers

Even the whiteboard is not strictly necessary. I have often found myself standing with others around a blank wall and "drawing" on it with our hands! It works surprisingly well for high level discussions, and the group seems able to envisage the invisible picture. This is probably indicative of the power such BigPictures have.

Of course, whether we're all envisaging the same picture is another question... :-)

-- TrevorMendham

Yes just watch the fingerprint tracings on the wall while the arms swing around like a mad man. Better grab some large paper, an overhead machine, or a binder if the specification is to be clear!

Teams that successfully apply graphical methodologies always customize them to meet their local needs: So don't be afraid to draw a (heretical) non-standards-conforming document (in violation of the UML religious doctrine!!!).

For example, in a recent project I worked on, our most useful high level diagram was a strange cross between a StateTransitionDiagram and a DataFlowDiagram: Small boxes for the states that records may be in, with larger boxes (instead of circles) for processes. Also, creation and deletion of records was indicated, in addition to the STD conventions of changing (updating) state. It was the constant companion of developers, trainers, support and operations personal. And it did not conform to any widely accepted diagramming standard.

Ad-hoc graphic formats can be very powerful - consider any effective overhead presentation (via PowerPoint, for example).

I once conveyed the system's inventory tracking policy to our customers by drawing their warehouses and trucks, and coloring regions based on inventory policy: IE: If the part is here, then it is valued with policy "X" (...with a color for each policy). It was effective. -- JeffGrigg

I often draw big pictures for myself to understand something. If I draw pictures electronically I use a creativity tool called Mind Manager. See MindMap. -- FrankGerhardt

Nearly every successful project I've worked on has produced a small set of drawings that showed the key entities in the system and how they related to each other. These diagrams are usually some type of ER diagram, but I've also seen (and used) event traces to capture the essence of interactions. For whatever reason, I've seldom seen class hierarchy diagrams be part of this central core of drawings.

I've seen a floundering project "snap into focus" when a good ER diagram was produced mid-project, and the disparate representations that people had constructed in their head after reading the code were replaced with a single explicit representation. I've seen a floundering project continue to flounder when the key developers produced partial diagrams that didn't "fit together" or didn't show a big picture. -- DaveSmith

CategoryVisualization