Chapter6.Modeling

Chapter 6. Modeling

People have been drawing pictures since the time of the cave paintings at Lascaux, and probably even before that. Man is a visual animal, so even after the advent of language we continued to record history and communicate with each other through graphics.^[1] It is hardly a matter of dispute that our eye-brain computer is a powerful tool that integrates an incredible amount of information extremely quickly and enables other forms of cognition to take place. Even our daily language reflects this; when we finally "get" something, we often say out loud, "I see it!"

^[1] Just to be clear, I would classify the wolf as primarily an olfactory animal.

Software developers allowed this visual capability to go unexploited for many years. Even though many people around them tried to describe (and get them to describe) the software they were building with rudimentary sketches, the response usually was, "Let's look at the code." That might have been OK if two software developers of approximately the same skill level were talking to each other; in fact, this notion led to the practice of code reviews, which is not a bad idea at all. But once you get away from the lowest level of detail, code is probably the worst vehicle one could imagine for describing software.

This is because it operates at the wrong level of abstraction. Simply put, it is too fine-grained. As soon as you need to describe how various parts of the code work within a subsystem, or how various subsystems interact amongst each other, you are at sea. Managers listen, draw their sketches of what they think they are hearing, show them to the developers, and usually get the response, "Yeah. Whatever."

Now I have to be careful here. In my advocacy for graphics, I need to also describe their limitations. For, as much as graphics can transmit valuable information, they can also convey lots of misinformation. I am not talking about technically detailed but inaccurate diagrams; those are quickly exposed. The truly dangerous graphics are the "management level" pictures that one so often finds in PowerPoint presentations. These pictures purport to tell us something, but in fact they are usually extremely vague and fuzzy. They are better than clip art, but not much. They can mean all things to all people. Because these pictures can be quite content-free, most software developers disdain their very presence. And, as most developers don't think it is part of their job to accurately communicate through graphics what they are building, we come to an impasse.

Our pictures are often content-free because everyone draws them differently. Different people use different symbols for classes, objects, subroutines, functions, databasesyou name it. When there is no common notation, everyone struggles; it is as though you are all speaking the same language, but there are too many "dialects," and the dialects lead to miscommunication. Because graphic representation is generally pretty arbitrary, no one can be "right." But that doesn't stop people from defending "their" notation, sometimes with an almost religious fervor. The diversity of styles actually retarded the adoption of a graphics notation. So that was a problem.

This, of course, masked an even deeper problem. Because there was no common graphical notation, we could not even begin to attribute semantics to the pictures. What do I mean by semantics? Semantics, in some sense, is what adds true content. But first of all let's get a better understanding of the problem of notation.