URBAN5: A Postmortem

“Yes. But not one of those antiquated adding machines. It will be a superb, super-hyperadding machine, as far from this old piece of junk as you are from God. It will be something to make you sit up and take notice, that adding machine…. It will be the culmination of human effort—the final triumph of the evolutionary process.”

Elmer L. Rice, The Adding Machine

Too often a research proposal has to establish the project’s worth so completely that the acquired budget is used for the development of an already worked out but hastily assembled idea. However, through the generous support of I.B.M. and M.I.T., URBAN5 did not suffer from any symptoms inflicted by proposal writing. There was no proposal. At first, not only were the authors unaware of how to get there, they were ignorant of where they were going. Work on Wednesday resulted from an achievement on Tuesday which appeared to be a good idea on Monday and might well be discarded on Thursday. The spontaneous nature of the project did generate unexpected and fascinating results. URBAN5 is not a tool, it is a toy. Its impetuous nature contributed, however, to some major shortcomings.

Of its many deficiencies, URBAN5 has four notably severe shortcomings that have been the primary cause for abandoning it, are the underlying reasons for writing this book, and will be the germinal concerns of our new system, the architecture machine. It should be noted, however, that none of the drawbacks stems from the selection of the ten-foot cube or any of the other abstractions; rather they are failings engendered either by a lack of knowledge or lack of forethought.

The first problem is due to the original oversight of evolution. URBAN2, the baby brother and core of URBAN5, presupposed a rigid system, concluding that all the embedded assumptions about the design process, where true (because many designers agreed), were fixed (because computer programs are that way, so we thought) and were universal (because that would be nice). After certain enlightenments, particularly that machines can grow and self-improve, some maturation processes were appended to the system. Parts of URBAN5 actually do change and develop over time. In a patchwork manner the system can transform some of its internal workings. However for the most part, the authors’ underlying presuppositions about the design process exhibit no evolution. URBAN5, as it stands, can never be denuded of the original biases that are deeply, sometimes unconsciously, rooted in its skeletal structure: that architecture is additive, labels are symbols, design is nondeterministic. URBAN5 can not display an attitude that contradicts these preconceptions.

The general structure of URBAN5 has a second critical failure. The system feigns generality by providing a multitude of specific, predetermined design services. It has over one thousand operations that in combination with one another support a good chance for providing a desired service. But URBAN5 is not a general-purpose architecture machine; instead it is a barrage of special-purpose (little) architecture machines. Each routine does a particular job and only that job. In computer-aided design, we have seen that this is not appropriate.

The third problem is context. Even though a contextual cross-referencing does occur within URBAN5, cues are explicit statements on the designer’s behalf. The underlying modal organization imposes the categorical testimony that “Now I am going to do this … and now I am going to do that.” This unequivocal demarcation by the designer of design context is completely unacceptable. It does not admit the necessary ambiguity and the subtle intermingling of contexts that are required in order to respond to a real-world medley of events. URBAN5’s operational structure demands a repartee that relies completely and at all times on the good judgment of the human designer. Again, this is not acceptable. Can we assume that he always knows what he is doing or what he will do next? Professor Licklider’s (1965a) solution is that “the console of the procognitive system will have two special buttons, a silver one labeled ‘Where am I?’ and a gold one labeled ‘What should I do next?’” Even this solution is only partial. The machine should answer those questions implicitly, using context as the prime operator. Context must be articulated through many channels, rather than the simple depression of one or two buttons.

Problem four: URBAN5 holds hands with only one designer and not even enough hands with that single user. The designer has a light pen, a keyboard, and a few buttons—a meager selection of communication artifacts. The machine, in turn, has only a monotonous buzzer and the cathode-ray tube upon which it can trace monochromatic characters, lines, and points.

The hardware sensors and effectors of URBAN5 cramp those styles of conversation that are necessary for a dialogue. The hardware has no contact with the real world except through the designer. URBAN5 cannot hear the designer, it cannot see the designer, it cannot see the designer’s world. The designer, in turn, can hear only a penetrating buzz or irritating hum from the machine. A future system must have overlapping modalities and a full range of sensors and effectors.

Any postmortem statement should do some eulogizing. Even though URBAN5 was a bit talkative and was a sloppy problem solver, it was a friendly system.