The technique of factoring at the source code level is discussed as a means to reduce complexity, along with an admission of the very real difficulty of actually performing good factoring of source code. The utility of object oriented programming methods is praised, but with reservations: object oriented programming is still in its infancy, and is proving to be a difficult child.
Analogies are made to show the similarities between programming systems and techniques that most programmers regard as being quite different. Analogies are also made between programming and electronic and mechanical design practices. They show that programmers are not alone in having to deal with the complexity of design and maintenence.
Finally, the mechanical and electronic design practices of drafting are briefly discussed, and a case is made for graphic aids to programming. The analogy between pointer diagrams, control flow diagrams, and dataflow diagrams on the one hand is made to the circuit diagrams of electronics on the other hand. A case is made for CASE: Computer Aided Software Engineering; automated graphic tools can greatly ease the programmer's burden.
Although the tone of this paper is somewhat humourous, some very serious points are being made. I am trying to show that the very nature of the work we perform is difficult, and although good approaches to design help, they are not a substitute for the hard work required to develop a conceptual understanding of a system. Roger Shank, of the Yale University Artificial Intelligence Project, stated, "As anyone who has ever worked on a large software engineering program knows, this task is so complex that it makes all other problems pale by comparison" [Shank, R. 1987 "What is AI, anyway?" AI Mag. Vol 8 No 4 p 61].
Different approaches to these problems lead to different views, and hence different solutions, but any given view becomes overly complicated when we wander too far away from the simple looking starting point. The goal of this paper is to show ways in which one view is similar to another, thereby permitting us to perform a mental transformation of coordinate systems, as it were, from our initial view into a different view, where things once again look simple.
This concept is reminicient of Einstein's view of the physical universe: things only look simple if you don't look too far. Einstein's triumph was in providing us with the tensor calculus that permits us to change coordinate systems as we approach the edge of complexity, giving us a fresh and once again simple view of that which previously looked too complicated to understand.
This paper, while not reducing the problem to a procedure, attempts to illustrate ways in which a view of a portion of a program that looks overly messy can be recognized as "the same as" some other more familiar problem. This fresh outlook can make the problem managable once again.