I finally finished Daniel C. Dennet’s book “Darwin’s Dangerous Idea”. I wrote about already it in one of my first posts, Simplify to Understand, where I found an analogy between a claim in his book and my own ideas about software. I cited the book and explained my own idea using Dennet’s view.

Interestingly, in the process of finishing the book in the last couple of weeks, I found another analogy. Namely, I found a passage in which he explains a remarkably similar idea as I set forth in my post “The Three Pillars”:

If you know something about the design of an artifact, you can predict its behavior without worrying yourself about the underlying physics of it parts. Even small children can readily learn to manipulate such complicated objects as VCRs without having a clue as to how they work; they know just what will happen when they press a sequence of buttons, because they know what is designed to happen. They are operating from what I call the design stance. The VCR repairer knows a great deal more about the design of the VCR, and knows, roughly, how all the interior parts interact to produce both proper functioning and pathological functioning, but may also be quite oblivious of the underlying physics of the process; they are the ones who must descend to what I call the physical stance in order to figure out what sorts of design revisions might enhance picture quality, or diminish wear and tear on the tape, or reduce the electricity consumption of the product. But when they engage in reverse engineering —- of some other manufacturer’s VCR, for instance —- they avail themselves not only of the physical stance, but also of what I call the intentional stance —- they try to figure out what the designers had in mind. They treat the artifact under examination as a product of a process of reasoned design development, a series of choices among alternatives, in which the decisions reached were those deemed best by the designers. Thinking about the postulated functions of the parts is making assumptions about the reasons for their presence, and this often permits one to make giant leaps of inference that finesse one’s ignorance of the underlying physics, or the lower-level design elements of the object.

What Dennet means by design stance, is what I think the first pillar, namely the functional level of looking at a designed artifact. The physical stance maps onto the third pillar, namely the implementational level, and the intentional stance is what I describe as the architectural level, as the second pillar.

What is especially interesting is that, examining a designed artifact with knowledge only from the design stance and physical stance (in pillar terms having only the knowledge on the functional and implementational level) it is very difficult to make statements from the intentional stance (or on the architectural level). In other words, when you know about the function of a program, and you have its source code, devising its architecture with only that is hard. That’s why, for maintainability purposes, it is wise to some way or another document the architecture, or design intent, for software. Obviously this can be an separate document, but it might even suffice to add the right comment in the code. As long as the intent of code is clear, it will be much easier for somebody else (and also for yourself) to use, change or extend it, using the original ideas you had in mind when you first wrote those lines.

At least, if you have considered the architecture of your code, which I believe you always should.