Fractal Comprehension

Comprehension at all levels of focus. A goal for design (Admittedly, Pie In The Sky). Given a codebase, one should be able to understand the system as a whole, each module, each class, each method, each line and each SequencePoint at the same level of understanding. This applies to other fields than software.

I see it differently. Given that all things are arbitrarily complex, you can only comprehend fractally. You start with any part, and understand some outline of it. Over time, you can refine your understanding of its "true" shape better, meaning you see the next set of curves and the ones after that. Do you ever reach completion? No more than you ever reach the limit of a fractal curve. And all that is only on one section of the overall shape. As someone wrote on the other page, "After 30 years of using vi, I am finally starting to understand it." Fractal Comprehension is not what "is", it is an echo of the "way we understand" - we proceed toward understanding of a topic as we can proceed toward understanding of a fractal. -- AlistairCockburn

You also run into a corolary of Goedel's Theorem called the Generalized Uncertainty Principle(sp?) of GeneralSystemantics -- any sufficiently complex system exhibits unpredictable behaviors. --DickBotting

An example of the failure of the Pie In The Sky form of this idea in software development is the emphasis on class design.

When given only the source code as documentation, a hapless programmer's largest scale of abstract is stuck firmly at the class level. However, this is most infrequently the best level of abstraction to understand the language.

Compare comprehension of a RealWorld system like a car. One does not attempt to understand the nature of the engine by staring at each part at a focus of two inches! One has an overall view to begin with.

Within software, it is difficult to comprehend the overall object network and how the various pieces interact. In Smalltalk, you can get a callers list, but this is impossible in post-compile, linked languages like C++. Even then, this really doesn't given one a good perpective to understand the overall mechanics of the design.

The solution given these days are a combination of documentation, especially UML diagrams and DesignPatterns, which simply spooge the documentation into a common text. Not a bad thing, as one would need a solid comprehension of the principles of engine design to comprehend modern car engines, but not sufficient.

Another solution coming from the world of databases is the concept of schemas at the same level as objects. This would effectively publish the object network instead of burying it behind an encapsulation layer. [cf DDJ Nov'99 for an article on this.]

Unfortunately, this solution delocalizes control of an class's inter-object interaction and possibly puts it out of control of the programmer (especially in rigorously controlled environments; third party libraries; legacy code; etc.)

UML diagrams are not a solution but more of a reaction. Documentation separated from the code will in general be incorrect, difficult to maintain, and hamper development. (cf. TheSourceCodeIsTheDesign; SelfDocumentingCode)

Code generators have made UML diagrams more like the programming language. Perhaps this is not a bad thing. Perhaps more VisualLanguages would be useful. We certainly have GUIs available. The addition of a second dimension to the source code can only serve to reduce complexity...

Code generators have made UML diagrams more like the programming language. Instead of a code generator, why can't we have the inverse: A program that generates UML from the source code?

Both of these are available for Java.

Together Control Center is an IDE that also allows to draw UML diagrams (like Rational Rose), keeps diagrams and code synchronized when you modify either and can also generate written documentation from diagrams and Javadoc comments. Warning: buggy and expensive

--- CategoryAnalysis CategoryEducation CategoryDocumentation