Discussing why programmers call themselves architects and why architects take up C++. An inquiry into the relation of today’s Architecture and Programming.


I am an architect – by profession, way of thinking, architecture of my mind. When someone else takes the term “Architect” from the context and calls himself that, I ask a pretty legitimate question – why? For some reason, everybody wants to be an architect. There are architects of legislations, software architects and all other sorts of architects. In this essay I shall look specifically at the relation of software architects and architects. Why do they use the term and what does it mean when they acquire it? We shall also look at why the trend is mutual – more and more architects tend to become programmers – and what this trend means for architecture.

First of all, we need to understand what an “Architect” means. The common understanding of an architect is that it is the designer of buildings. His responsibilities and the overall necessity are constantly questioned in our culture of speed and efficiency. To developers, an architect is someone who never wants to do what they are told to do easily and without altercation. To the engineer, he’s the source of all the problems and unnecessary complications. To the public – he is a mystical hero. To women – the sexiest man alive. But what is the reality of the architect?

The word architect comes from the Greek αρχι – first or main, and τεκτον – builder. In the beginning architects were chief stonemasons, who controlled and directed building operations. In the course of time, with emergence of new technologies and complication of designs, there emerged a necessity for someone who would overlook the process of building and control it, what we might call, holistically. Architects gradually separated themselves from stonemasons and became the people who knew how to make things without necessarily being able to make them – know how to cut stone and in what shape, but without a technical skill to do so. The responsibilities and (interests) of architects became more and more subtle and “broad” – overlooking the process, controlling the system as a whole, instead of lifting pieces of stone into place. Architects became more concerned with how buildings “work”, their aesthetics and phenomenology. This progression explains the elevation of the status of an architect and his resulting “godly” aura.

Of cause, the “godliness” of architects has been criticized throughout the 20th century as being too abstract and away from life. However, one might say that these protests were against the application of the term architect by individual architects, who “thought too much of themselves”, rather than the concept of an “architect” as such.

Here we come back to the question: what is the relation between the two fields – architecture and programming? Why do programmers and software engineers like to call themselves architects?

Well, from the above description it becomes apparent why. The holistic interest for the overall functioning of a system and the ability to make the system work is what defines an architect. This concept finds its application both in architecture itself and in other disciplines. Hence, the use of the term in so many instances – software, legislation, Jefferson – “an architect of the American Constitution” (interestingly enough, he actually was an architect by trade). As for software engineering, Wikipedia (although an unreliable resource according to some) gives a fairly good explanation of the reason for using the term “architect” in software engineering. However, it is necessary to stress here that the term is always used figuratively. Let us not forget that a real architect also deals with fire codes and zoning regulations, oversees the construction process in physical reality, and, therefore, has a whole broader – and more practical – value.

However, the more I look at architecture (real architecture that is) today, the more I see that nowadays the trend has reversed itself: not the programmers are borrowing the title of architects (they’ve done that already), but the architects themselves are more and more becoming programmers. Therefore, architecture is more and more becoming not the art of drawing and visualization, but a programming discipline. We “write”, “script”, “code” and “program” architecture. How does the blending, or mutual mimicry, of both professions influence and inform each other?

I personally find that the aspect that ties the two fields the most is that programmers create new realities – that is why they might call themselves architects. One of the things architects do is produce realities. I believe great architectural minds have arrived at this far before me and there are tons of books on the subject, but for me this phenomenon became obvious after watching the film “Inception”. The film is about dreams, but the guys who make those dreams are architects. Dreams are not real space, but they are still realities. That is why we automatically translate them into 3D. 3-dimensionality of our thinking is a built-in mechanism. Architects happen to be the professionals that specialize in producing 3-dimensional environments, and with this, they are producing our realities – ones we can play around with, be inspired by, believe in and inhabit. The same is with programming: although it is not real space, it does result in new realities – virtual ones. Programmers are the architects of virtual realities. But what is different between the programmer, and the real architect is the output. The designer produces the reality we live in metaphysically. It can and does define our physical behavior, but it is not tangible. Architecture is tangible, or at least that is what it used to be for the last couple of thousands of years. Architecture steps one step further into reality than any programmer can – it actually builds itself in the real physical world (“Why do I think that physical is real” is a valid question here, but I shall just dismiss it now for the sake of the argument – I beg your pardon).

Is becoming tangible – a step further or a “step too far”? A programmer can change his “building” at any moment of time by minor alterations of the code, which results in immediate changes in the substance of the “structure”. Architecture cannot do that. Once it’s built – game’s over and though we’ve been battling with the static nature of the artifacts of our profession for years, architecture still remains static.

Which brings about the phenomenon of the double life of architecture: before and after construction. In the last decades we’ve seen a tendency to over-emphasize the first life of architecture – the research and conceptuality that come before the fact of construction. Some architecture cannot exist in built form, some doesn’t even want to – take a look at Archigram’s earlier works or Peter Eisenman’s writings to make that sure. However, one might argue that the life of architecture after construction is actually its real life. You may play around with architecture as much as you want, but the preeminent characteristic of any architecture – shelter – is still the last thing that will remain (or not) of any architecture “once the lights go out”. Programmed realities – will not. May-be architecture’s static character is exactly “the” virtue and “the” defining aspect of the field?

But what about the script?

In the recent years we have seen a boom in computational technologies application to design. CAD, 3D modeling, parametric design – all use programming as a base. And if it began with timid explorations of CAD by architects, who were afraid that machines will take over their work (a form of Ludditism), by now architects are writing their own scripts to alter the behavior of the software packages they are using to enable them to design more and more complex geometries. Architects are becoming programmers.

The IT architect programs his code in… I don’t know, really – is it space? Because whatever a real architect does, he always does it in space, in 3D. Or does he? The drawings of elevations and sections, etc. are only translations of space onto a 2D plane. But scripting is a whole new territory for architecture. It has nothing to do with space. Or does it?

As Robert Aish of Betley Systems writes in “Game Set and Match II” (2006), with the introduction of algorithms and computation into architecture, there appeared a duality in attitude towards the methodology of design. “This is the shape I have sketched, but how do I formally describe it” versus “This is the formal shape description system I am using, how do I harness and control this system to create the shape I like” (p.203) In the “description system” Aish refers to is computation. Aish goes on explaining that, with scripting the architect moves one step higher on the ladder of control over design. He is not designing the artifact directly any longer. He is controlling the way it is being designed. If you look at it broadly, then this is exactly the attitude of such heroes as e.g. Frei Otto or other “form-finders” – they want, in their case, “nature” to design a building for them. And nature is the “system” that brought them to the form. Now, “the code” is that “system”.

Architecture of tomorrow (read: today) is scripted.

It is being described in a language. This language is both highly technical and exact, and highly abstract. However, this language is capable of defining spatial relationships, which have the potential to be ultimately petrified as architecture. Criticism of such architecture (as a process), however, has been and still is that some architects prefer to keep playing with their designs and never make it into the built form.

We use the same language (let’s say C++) to write both web-sites and architecture. With the same programming language we express both the metaphysical world of the Internet and video-games, and the real world of the built environment. This language has the capacity to be translated into anything. We might even talk and live in it, if we choose to.

But what does a programmer/IT-architect mean by saying “Oh, that’s a beautiful code!”? As a “user” you never see the code behind the interface, just the way you never see the code behind the façade of a building as a “visitor”. The code is something underneath the surface. What you are presented with is the surface – smooth and shiny, as a mirror. Behind that surface though is a whole world of relations, wires and transistors. It works the same way in architecture – only that before, the code used to be the drawings, now the code is – the code itself. It has become even more sophisticated. The code is like a system of proportions and measurement in the architecture of Renaissance: you cannot feel it, you cannot tell straight away what’s going on, but somehow the facade makes so much sense to you. It looks beautiful. And it is so because it is governed by a system.

proportion system -> code

code -> proportion system

The code is the new proportionate system for architecture.

Probably, soon we will be judging architecture by its code, saying “Oh, such a beautiful or ugly, parsimonious or lavish, elegant or shameless code”. In the future there probably will be no more visualizations or plans printed out in black ink on A1-sized paper. The only (necessary) way for a tutor to judge the work of a student will be by the code of his design. Then you will enter the code into a huge automated “rapid builder” (as an evolution of a “rapid prototyping” technology), or, better yet, program it into a “cell” that will grow itself into a piece of architecture, as an organism grows according to its DNA code (again – “code” – one more point for code in architecture – we want a truly biomimetic architecture, don’t we? Code seems like a way to go!) The building will construct itself according to the code, without need for any intermediate stages. Everything will be accounted for in the code.

As we see the two fields are much more intimately related than one might think at first glance. The constant exchange between Architecture and Programming not only results in more and more software applications being made available to architects, but also makes the very ontological nature of the both fields mutate and merge. What comes out of this symbiosis – we shall see.