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.
Aaron Westre
I admire Brooks’ pragmatism and willingness to modify his strategies when new evidence presents itself. His writing is canonical in software development for good reasons. When I first read The Mythical Man-Month, it explained very clearly why the management of complex projects didn’t match the reality of their execution. When I moved from information technology to architecture, I saw the same dysfunctions that were present in my work as a software developer. The two fields have a lot in common: fuzzy problems, complexity and collaboration.
As someone who straddles the line between these worlds, like many who read this blog I suspect, I see a lot of benefit in the transfer of knowledge between them. However, despite the similarities, there seems to be some fundamental differences in language and thought that prevent the two disciplines from taking full advantage of this transfer. I think Brooks’ description in the new book of his house design software is a good example. When a computer scientist looks at architecture they see a data processing problem. Similarly, when architects look at the work of computer scientists, they see evocative images in the algorithms that render mathematics as sensual curves, Voronoi diagrams and other forms. I’ve often been guilty of this kind of naive reading on both sides of the divide.
I think the naive transfer of little techniques from computer science to architecture is fine as far as it goes. The missed opportunity, I believe, is the transfer of the bigger concepts that could change architecture in very pragmatic ways. The problem discovery territory that you mention is an important one. There have been some major advances in the building of software for sense-making: knowledge acquisition for doctors, improved search algorithms, IBM’s new Jeopardy champ Watson; to name a few. Software that helps architects define their problems by pointing out relevant research in architecture, planning, materials science and engineering could be an catalyzing force. Similarly, appropriating project management techniques from software development such as file versioning systems and agile development practices could have a profound effect on the practice of architecture. Video gaming is another area I’ve been investigating for its potential to inform the creation of engaging and productive tools for design.
We architects need to rise to the next level of theft (in a good way) from computer science. I think after about 50 years of predominately amateur fascination with digital technologies, architects are finally ready to look past the surface for more valuable plunder. We, like computer scientists and other creatives, are responsible for envisioning the future. This same aptitude can serve us well as we attempt to transfer some big ideas from the discipline and practice of computer science. Hopefully we will seek out their help with this task and transfer some our big ideas to them in the process.
Sivam Krish
I have been reading the “Design the of Design ” I am halfway through it. It is a wonderful book. Brooks takes the pants off those serious heavy duty designer procedurist who publish in volumes and never design a thing – misleading a large amount of graduate students in procedural exercises that have no hope of being used or being useful.
Brooks understands not only the nature of design but the leadership qualities that need to accompany it. And the human dynamics that need to be managed.
Daniel
@Aaron:
Sorry I did not reply sooner, but thank you for a comment that is more articulate than the post!
You really capture the nuances of how architecture and computer science are coming together. I find it interesting how the issues with “fuzzy problems, complexity and collaboration,” are almost universal across medicine, business, architecture and programming, but we have all been dealing with it inside our own domains. Currently it feels like that period after an exam, when tests are handed in and everyone is sitting around sharing the answers – I think this cross fertilisation could be really productive. In a Wired article (http://www.wired.com/magazine/2010/07/ff_fred_brooks/) when Brooks was asked if he expected non-programmers read Mythical Man Month, he replied: “No, and I’ve been surprised that people still find it relevant 35 years later. That means we still have the same problems.” Which I think sums up the universality and persistance of these issues.
@Savam:
I agree and I am half tempted to give ‘Design of Design’ to a friend lecturing a first year architecture course. It certainly makes a lot more sense than the texts we were given. The only unknown is whether Brooks makes sense to someone starting out, or whether it is the sort of thing you can only appreciate once you have battled through the maze of design processes to a position similar to Brooks.
Sivam Krish
Daniel,
The difference between architecture schools and engineering schools is that in most architecture schools they do not teach design theory. In engineering schools they know it is important – so they hire someone who has never done it , but published enough about it to teach.
Brooks reacts to this in his book. He even cautions journals not to accept certain types of papers!
I like the fact that he does not propose a method, but shares his wisdom that he has had developed over the years in many different domains – with rare humility.
Sivam
Matthew
As someone with a degree in Computer Science and one in Industrial Design, these two books sound interesting—thanks for pointing them out. I couldn’t help notice a few errors in the post though:
Fred Brooks won the Turing Award in 1999. The Turner Prize is a British award for contemporary art.
There are 256 colors in a color picker (2^8), not 265.
M
Daniel
Thanks Matthew, I updated the post so that Fred Brooks is no longer an award winning artist as well – although it wouldn’t surprise me.
Industrial Design + Computer Science sounds like an interesting combination of degrees. I get the impression generative/computational design is not so big in Industrial Design (apart from making novel mass-customized objects and solving hard problems like arial design). Is that your experience?
Matthew
I’m not familiar with Arial design and a quick Google didn’t help me out… what is it?
Parametric design is definitely more prominent in architecture than in consumer products. To me, it seems the trend in architecture is one that’s comfortable with decorative (irrational?) facades that have to fit within broad parameters, but aren’t always driven by function. (This isn’t a negative judgement and certainly some of the parametric work is done to aid construction or achieve something otherwise impossible, but often it’s to create visual novelty.) In product design, however, we are definitely in a modernist era (Apple, Muji) where many people are revisiting Rams-era Braun. I think part of it is sustainability-driven—people want to buy things that will last, both in terms of quality and style. Simple things tend to be timeless.
However, architecture often precedes industrial design, so maybe we’ll tire of our simple, geometric products and yearn for irrational forms. Maybe we’ll compromise with generative textures over our rational forms. Often I’ll see a piece of generative architecture and think how cool it would be to have it scaled down to a handheld product that you could run your hands over.
Daniel
Sorry that was another spelling mistake, I intended to say ‘Aerial design’ – I have seen a few papers on using things like Genetic Algorithms to optimise them, often with unusual (and human comparative) results.
I agree with your distinction between the two disciplines. It is a curious world we live in when industrial design is concerned with being timeless and sustainable, while architecture is being influenced by fast-moving electronic trends. I think in architecture, particularly after post-modernity, there has been a pressure on architects to justify geometric form. From this, the ‘objectiveness’ and ‘infallibility of the algorithm has become appealing – ironically to justify the irrational. It will be interesting to see how long architecture stays with this, and whether ID does follow or side steps it altogether.
Basem M.EID
Is the process of designing a computer system to be employed in solving architectural problems, similar to the process of desiging an architectural object?
this is a very confusing issue i guess