Fred Brooks once made up the term ‘computer architect’ to describe himself. In the process he created a whole new (and lucrative) job type. It is an apt description of Brooks, whose entire career entangles computers and architecture. If you read this blog, it is probably an apt description of you.
At the time Brooks coined ‘computer architecture’ he was project manager of the development of System/360 at IBM, a risky unification of the IBM product line that saw IBM replacing all of its computers with ones that were not backwards compatible with their old systems while their competitors released computers that were. These computers are the reason a byte has 8 bits, why colour pickers have 256 colors, and why you can only put 4gb of RAM into your 32 bit machine. Brooks reflected on his experience at IBM in his seminal book: Mythical Man Month, which explores the challenge of solving a complex problem with a large and disperse team. In it, Brooks explains how adding people to projects can make the project slower, why 9 woman can not make a baby in one month, and why architects and programmers are alike.
His latest book The Design of Design: Essays from a computer scientist (2010) is perhaps more architecture than it is computers, but it follows a similar vein to Mythic Man Month of examining how to organise and manage, complexity and creativity. There is something refreshing about about a book that places design as the central focus of design. The text itself is peppered with quote worthy soundbites: “the hardest part of design is deciding what to design.” This quote builds upon Gorden Glegg’s assertion that “sometimes the problem is to discover what the problem is” and follows Brook’s own argument in the book that computer scientists (or designers) cannot fully describe a problem until they start working on it. Part of the programming (design process) is discovering the problem. Initially it concerned me that much of what Brooks was saying was never taught to me in architecture school, although on reflection I think it implicitly had. As Morpheus said in the Matrix “there’s a difference between knowing the path and walking the path,” and at architecture school I definitely walked the path of design.
The design part of the book is interesting, especially at a time when architects are drawing so heavily upon the work of computer scientists, it is nice to see things go back the other way. But by far the most curious part of the book is the two chapters that follow the design section, the 26 pages Brooks writes about “A computer scientists dream system for designing houses.” Brooks has some experience designing houses, listing himself and his wife Nancy as the architect (‘architectural designer’) on three house designs, which are treated as case studies later in the book. I find this section curious for a couple of reasons:
Firstly it serves no obvious purpose in the book. I like to think of Brooks cursing at his CAD software and vowing he would write a book about how to do it better. There is something comforting to about an 80 year old man responsible for many of the features of modern computers, a man who has won the Turing award in computing, struggling like you and I to use CAD software. Although apart from humoring fellow architects, it is hard to know the exact point Brooks is trying to make to his fellow programmers in this fairly large section of the book.
Secondly after saying all these wonderful things about design being problem discovery and design not being a suitable candidate for AI, Brooks ends up describing the worse CAD software since 3D Dream House Designer 2000. In Brooks’ program, the architect describes a house using their voice:
Give me a three-bedroom Georgian House… Face it North… Mirror-flip it left to right.
In his software, Brooks seems to have forgotten all those wonderful things he said about the design process, and instead has created a fanciful interface for describing a building, which it is totally inept at aiding problem discovery. The juxtaposition between the early sections of the book on what design is, and the later sections of the book on what a ‘dream system for designing houses’ consists of, almost seems like a devastatingly crafty critique of computational design. Indeed it is true most CAD software today focuses on solution descriptions, as evidenced by CAD typically being brought into projects during the detailed design / design documentation stage after the primary problems have been discovered – Frank Gehry I am looking at you. Even when the digerati work with computers early in the design stage of a project, the application is typically so contrived that at best it is solution discovery (but normally it is just solution description through a very convoluted language). So I am left wondering what a dream system for designing houses would look like? I am left wondering whether computers can ever be part of problem discovery? And as ever, I find it somewhat unnerving to have our assumptions about design and CAD software spoken back to us by the first computer architect, Fred Brooks.
Cover image, Fred Brooks by Marco Grob.
12 March 2011: Matthew Grayson has kindly pointed out that Brooks won the Turing award, not the Turner award, and that it is 256 rather than 265 colors in a color picker – updated accordingly.