Bless Ross for pulling together all of the conversations that emerged from Cory’s 2004 wish. After pulling together the strands, he offers his own perspective and i particularly like his commentary on openness and control.
When we refer to the regulatory forces that include “code,” we’re almost always referring to Lessig and his book of that title. In it, he references code as the architecture of the digital world. It’s a great metaphor, but perhaps we should consider some of the physical issues that surround physical architecture. [If there are any architects out there, pipe in!]
When an architect designs a physical space, there is rarely iteration. I don’t mean to suggest that buildings don’t learn; of course they do. What becomes extensible about a physical architecture is how it can be repurposed. See, the designer, creator and constructor of a physical architecture usually turns over the creation to the users. This is not to say that there’s not a manger of physical architectures, but the manager is rarely the creator. At most, the manager calls upon the constructor to fix or alter something. Seriously, how many architects are there that obsessively design, fix, maintain and control a building?
The distribution of creation, control and use of physical architectures is a truly distributed process. Many architects are probably a bit horrified by how their constituents use their constructions, but they don’t play wack-a-mole with their users (although it is funny to imagine the ghosts of architects past coming out of the walls screaming that a painting is NOT supposed to be placed there). And users are certainly never fully pleased with the creators. I can’t tell you how many Media Lab students damned I.M. Pei and that darn artist who made it impossible to get light in the building or create a feeling of connectivity.
It’s funny because we don’t ask architects to iterate on their creations based on use, but we do ask that they create structures that allow for a variety of different uses. When they don’t, their creations become outdated and unusable. How much of this applies to code?
While the metaphor of code as architecture certainly makes some sense, there are lots of ways in which software architects are not similar to physical architects, both in how they treat their creation, its longevity, its users, etc. But perhaps there are some ways in which they could learn from one another…
This may be a bit off topic but as I did the audit of the security of some local government networks, I was reminded that I’ve NEVER seen a computer system that was actually built exactly to spec. Furthermore, when a contractor delivers a building to a contractee, there is a system to check and make sure that the building that is delivered is what the architect designed. Not so with computer systems. It is much too complex and “invisible”. This is one of the reasons I think voting machines suck. You never REALLY now what’s inside.
So the differences are obvious. I think the similarities also exist. When I visited Hvittrsk in Finland I was struck by how the three young architects had designed their whole lives around their philosophies and how in the late 1800’s the excitement around architecture was similar to that around computers today. So much progress, so much technology. The notion of rebuilding a whole city from scratch based on some notions of new lifestyles was met with as much more more skepticism than Friendster or LinkedIn.
Maybe years from now we will look back at the discussion we are having about architecture and it will remind us of when discussing this stuff was actually a new idea.
hmm… i see a lot of similarities. most software architects i’ve watched in action never really listen to their users. big things get beat over their head, but they tend to live in their own world of abstraction somewhat disconnected typically from how the users actually interact with their creation. that’s why they evolved into architects I suspect, because they prefer to synthesis large abstract systems as a creative process. but that preference for staying abstract also cuts them off from the detailed perspective on how their creation is really used in my experience.
A friend pointed me to this excellent discussion, since some of my work revolves around realspace architecture and what digital architecture can learn from it. I’m not quite sure that I agree that there is rarely iteration in realspace architecture — indeed, much of architecture involves replicating and expounding on innovations by others. To be sure, each individual project is rarely altered by the architect themselves (as opposed to, as Zephoria says, the users), but the profession of architects, like the profession of software engineers and other coders, refines and adapts innovations made in an initial set of plans and uses the adaptations in future work. There is still a tremendous amount of centralized control in realspace architecture — both because of the ethos of the architectural profession and their prolicivity to follow trends [witness, for example, the striking conformity in all 8 wtc proposals], and also because of government regulation like building codes that makes it hard for non-architects to come in and try to push architects to do something differently from they way that they have been doing it or the way that they want to do it.
There are a tremendous number of things that cyber-architecture can learn from realspace study. For example, one of the most interesting findings from realspace is that open architecture can reduce crime. Most people think that gated communities, bars on windows, and seclusion will reduce crime. It turns out that our impulse on this is often wrong, and that opening space up, particularly in urban areas, is a much better tool for crime prevention. In sparsely trafficked areas, by contrast, the physical gates and other tools make more sense. If you flip that principle around to cyberspace, it suggests that the claims being made about open source security by both sides (that it is inherently more or less secure) need to take account of similar phenomena. That is, open source code can be more secure if the code is such that many eyeballs will be looking at it and refining it (like a linux platform) but may be less secure than closed code when the app is so specialized that it would not invite the same distributed focus on security (such as software for specific financial industries). That’s just one of many examples of where our study of digital architecture can be informed by the physical. Consider also the way in which government regulates architecture via building codes, and whether there is a role for that in cyberspace (and not the mealy-mouthed Bush plan for cybersecurity). For more on the insights between realspace and cyberspace architecture, see the 2 architecture articles at http://www.law.georgetown.edu/faculty/nkk/publications.html
BTW, Joi, I am not so sure that realspace architecture is any better at checking to see if the building conforms to design plans. Much architecture is not at eye level, it’s what is in the walls, not what is outside of them. And most realspace clients are just as ill informed about the internal mechanics of architecture as the purchaser of a software system. In both cases, what the end user sees is only the tip of the iceberg, and an expert is needed to assess conformity, security, etc. Perhaps there is an analogue to the private building inspector who performs this function, maybe the tech officer of the company or an outsider.
Anyway, I applaud any effort to look for similarities and differences in the two fields.
Neal – first, thank you for that link to your work! I cannot wait to read it!
I definitely agree that both physical & digital architects learn from their predecessors in the field. That said, software architects iterate on the same construction after it’s built in a way that physical architects do not.
I’ve never studied architecture, but i was always amazed watching friends of mine do so. There was a whole process to designing say a building. And the little models. And redoing the models. There was so much back process, questioning of one’s decision through models long before thousands/millions of dollars were placed into the construction.
Now, i think of my own software development. Sure, i sat at the white board, designed the supposed extensible architecture, got feedback, etc. But all too often, we all dove into the code far before everything was figured out. We weren’t building models; we were building the real thing, that which would be deployed. The time pressure was to get a working artifact together, not a prototype model. I cannot think of a single piece of software i wrote where i didn’t, at the end, go huh… that could’ve been done better in the following n ways. Yet, it was done and deployed. Doing a rewrite, while often a wise idea is virtually never done.
Thus, at a process level, the physical architect never thinks of the possibility of fixing things as they go or rewrites. Their planning has too much at stake. The software architect can easily conceive of fixing things as they go (and they always do, even when it’s a bad idea).
A major thesis of Stewart Brand’s How Buildings Learn is that buildings change and adapt throughout their useful life, but that architects don’t learn from the way owners and inhabitants change buildings. Brand explains that there’s a big gap in culture and practice between architects, the builders who put the designs into solid materials, and inhabitants who change the building over time to suit their needs.
Adina – sorry for not being clear. I meant to imply that building learn through their use and the approach users have, not that architects pay any attention to this.