In this article, I would like to explain the inception and progress of a new way of designing architecture using computers. This has been my central focus of attention since 1989 and frankly, there is a lot that needs to be explained. However, I have attempted to go through this story briefly, pausing only to explain some intricate concepts. I hope those of you who are interested in this way of designing architecture will find this introduction useful.
But I was a troubled person and I stuck to my decision.
I liked the atmosphere and work ethics at Hafeez's office and the churning that was happening there. However I was not very happy in the way architectural designing and practice were being carried out at that office. I sensed that architecture was becoming more and more complex; yet we were using very archaic methods to both design architecture and express it later in reality. A lot of mistakes were happening in all that hurry. I told Hafeez, without fully realizing what I may get into: "I need to pause and think on how architecture is to be designed and practised. Maybe I will get into computing because I sense that it could help" That was somewhere in 1986. I was 25 years old.
The only knowledge I had on computing then was one short course learning Fortran during my 8th Semester at IIT; something that most of us architecture students there hated and none of us could relate to. All we did was write a program for obtaining the Fibonacci series. My prof was quaintly trying to introduce the concept of "iterations" -- I should thank him because iterations indeed is a central concept not only in computing but also in many things that a designer does.
Later on, when I really got into the subject of architecture representation, I realised that we are saddled with insights on orthographic drawings, perspective, etc. that were discovered during the Rennaisance -- almost 600 years back. Sadly, most architects accept that situation as a given. I guess many of us are so caught in the maelstrom of designing and the immediacy of construction, that it is difficult to take a step back and look at deeper concepts unemotionally.
What is even more puzzling is that after almost 25 years, I still find not many architects really understanding all this. I get all sorts of reactions, when I suggest that our traditional way of looking at drawings are completely out of sync with the complexity of today's information age. Many are terribly confused. Some graciously believe I am very eccentric and opinionated about this and politely step aside. A few are even quite vocal and emotional; almost on the verge of being hostile.
In the intervening 25 years, use of computing in architecture has surely evolved. But I am not sure if the evolution is in the right direction. Each day I wake up, I tend to re-examine the concepts of TAD; my central contribution to computing in architecture, and ask myself whether it is still relevant today. I examine this really critically. And each and every day, I truly find the TAD approach extremely relevant. This despite a long hiatus (I was embroiled in some other issues in my life) I feel like Rip Van Winkle: Waking up to see a changed, distorted world. A world where people have no time to think through deeper issues.
To add further to the confusion, I am quite critical about the so called new developments in architectural computing: Generative design, for example. Or the way BIM is currently carried out. Some of those architects who were initially puzzled and often annoyed with computing 25 years back, have jumped on to the bandwagon of the new BIM and CAD age without applying critical thought. I am still yelling in the background: "Hey, you still have got it wrong. There are serious issues that have to be considered" I was recently at a workshop given by an excited professor on new and clever approaches in architectural computing to students at a college in Navi Mumbai. She got scared when I got up to express my opinion and requested me not to ask any question as it may confuse the audience.
Some architects wave goodbye to me as they are happily carried on that train of branded software programs. Many of them gleefully use pirated software in their architectural practices. Some of those software companies are happy for the piracy: They have a smug smile of a pusher standing on the sidewalk handing free heroin shots to youngsters. Once hooked, they will surely will have to pay for the habit for the rest of their lives. (This has turned out alarmingly true for many architects in India: I've heard of offices getting legal notices for using pirated software. Those architects are arm-twisted into buying expensive legal software. They surely have to pay for the habit of using counterfieted drugs ... err... software)
It is not just that architects today are sucked into the glamour of software generating complex geometries. At least one can pardon them for that: Complex geometries does require software to do our work. However, concepts which I thought are rather easy to understand are skipped completely or glossed over. For example; I am yet to meet an architect who can fully understand the merits and disadvantages of solid modellers and surface modellers. For most, it is just some stuff happening in the innards of the software. "Why should that matter? Finally, I get to design and construct some real neat buildings, right? So what is all this fuss all about?"
If I draw an analogy now with a similar cavalier approach that was seen in the evolution of automobiles: People thought, why the heck should it matter how the engine worked and whether they used fossil fuels or not... After all, I can get from point A to point B so nicely. But now many do realise that ills automobiles have brought into the world: nasty accidents, pollution, global warming, wars to get to fossil fuels… and so on.
However, the same people happily use software that have come too fast off the oven without thinking through the deeper concepts. There is a growing population of architects getting into computing rather haphazardly with nary a blink of the eye. Many of the current approaches often does more harm than good, but architects are bedazzled by clever user-interface tricks, fancy looking geometries and insidious branding strategies adopted by commercial organisations.
Ill thought architectural design process can lead to really serious consequences out in the real world. When it comes to contributing to the problems of the world, architecture will easily lead over almost any other field. But are architects really listening? I wonder.
I think I must stop this vitriolic and explain what happened next in my life after I left Hafeez. What are the central questions asked by my way of looking at computing in architecture?
There are two that I began with:
a) Are we really representing EVERYTHING that needs to be represented in architecture?
b) Can we really handle ALL the questions that come flooding during the architectural design process?
And later there was a third one based on my understanding of the world at large
c) Do we really have the wherewithal to understand the COMPLEXITY of issues that architecture can get into?
I will explain these questions as I go along. Here is a bit of history of TAD.
My first question was assisted by my childhood friend, V. Narayan. He was having his own epiphany moment those days. He was supremely frustrated with the casual approach and lack of sensitivity in computing. He later moved to the US.
I drew a closed shape on a piece of paper and asked him; "You know what is peculiar about this? If I personify this paper on which I have drawn a shape as a person and asked that person what was the area of that shape, that person would happily give me the answer because it is already aware of the shape drawn on his 'body'. But me, as an architect, when I draw this shape on that paper; I really do not know the area. If I need to calculate the area, I will have to work with that shape once again, this time work out the geometry of that shape and then laboriously calculate the area. Isn't that a redundant procedure?" Narayan thought about it and said "You are pointed in the right direction. Once of the central principles of computing is to avoid repetition because if you are forced to repeat, mistakes can easily creep in. Now if you draw the shape once and to calculate the area, if you are forced to go over the points again … now that is asking for trouble"
Sure enough, this is one common mistake that can happen when using a drafting software: Sometimes a shape is drawn by placing lines that touch each other. They look continuous but actually aren't from the viewpoint from within the software. If you now need the area, you need to go over the vertices again. You miss one and you will get the wrong area.
The first program I wrote on a hand-held programmable calculator was a simple one that read out areas as I typed in the dimensions of each side of any shape with rectilinear corners. It was in BASIC and it did not have any graphical output. That propelled me to go further. I then wrote the same algorithm in a Turbo-C program with a nice spreadsheet type of interface. The foetus of TAD had just taken seed.
I realised that as an architect, we always deal in "well-formed" shapes. Shapes such as a figure of eight or a moebius strip cannot be really constructed (well a moebius strip can be constructed, but I wonder the practical architectural use of a one-sided surface) and my approach completely avoided those "ill-formed" volumes. (Which begs a sideways question on the fad on 'non-Euclidean' geometries in architecture… which strictly speaking are really not non-Euclidean at all. But I will desist as that topic is a digression)
Architecture does not have a concept of a "line" … that is just a drafting legacy we inherited from the Rennaisance and never questioned. The reality is that we always deal with volumes. That a volume has to be represented via its edges is a fait-accompli one is taught repeatedly at architectural schools.
While playing with all these algorithms, I stumbled into another discovery: That drawings really are not as complete as we make them out to be. An architectural drawing is simply the "remains of the day" after having "eaten up" the spaces that went into the design.
Let me draw an analogy to understand this issue: A coral reef is formed after the soft-bodies within the coral have all died and vanished into the sea. What is left behind is the exoskeleton of these organisms. In a similar fashion, when an architect conceives a design, he is trained to look at spaces as living, breathing "soft-bodies". Many architects use "bubble diagrams" to conceptualize space relationships in the initial stage of designs. However by the time that piece of architecture is created he has to create walls -- the exoskeleton-- around the soft-bodies and only those walls are seen as lines on the drawing. The soft spaces within the walls are not really represented.
Architects traditionally are taught to "re-create" those spaces in their eyes when they look at the drawing. So one glance at a drawing showing four walls enclosing a space will tell the architect that indeed there is a room in there. Hmmm…so what is this "soft-body" that I am talking about?
The subtle point that is sometimes difficult to convince architects is that when one represents architecture; it MUST be a complete representation. The architect must deposit ALL the constituents of the representation inside the medium so that they can be clearly picked up by someone else (or a computer program) objectively. Conventional drawings miss out on representation of spatial volumes, and there the background training of an architect is needed for the architect to interpret the spaces. A poorly trained or a fresh architect may miss out identifying some spaces.
In any subject of enquiry; knowledge that one is interested in appears in the "foreground" which is placed on a "background" of topics. The background only forms the context of the subject. For example; if one is learning how to draw; the actual drawing that one does would be the focus of attention -- after all, that is the subject of one's learning. It forms the "foreground". The canvas/paper/etc on which the drawing appears would serve as the "background". If a writer were to write a story, then the words he uses form the "foreground" and the medium on which the matter is written is the background. In short, there is a clear demarcation between the foreground and the background in all subjects.
Another word for the "foreground" is the "figure" and the "background" can be called as "ground". Architecture is one of those fields which is unique: Epistemologically, the subject shows a "figure-ground" confusion (Fig 1). Let me explain:
An architect needs to often focus his attention on the spaces within his design. In such a case, the "figure" is the space; and the walls form the "ground". However, sometimes the focus shifts from spaces to the built matter. In that case, the built-matter (walls) become the "figure" and spaces form the "ground"
When focussing on spaces, all the built-matter used to demarcate such spaces are not caught in his attention. Such built-matter is only the "ground". For example; when designing a classroom an architect may have to worry about the number of students in the class and how they may be arranged around the teacher, whether the various sight-lines in the class are appropriate, circulation of people within the class, whether all the chairs, tables can be accommodated properly; etc. All those questions are asked of the "space" within the classroom. When asking such questions, strictly speaking, the walls that are around the classroom will not play any part. (For e.g. whether the walls were made of brick or stone or cardboard partitions will play no part in answering such questions regarding the internal space)
However, the architect will soon enough need to focus on the walls (built-matter) of the classroom: Will they reflect light properly into the class? Will the walls attenuate sounds from outside? will the material used on the walls absorb sounds of the right frequencies? and so on. At that point in time, the space itself may not play much importance. And of course, there are times when the architect has to think both about the spaces AND the built-matter together. E.g: Acoustic performance of the entire classroom, energy consumed in the class, etc.
I believe, epistemologically, architecture is a very difficult subject due to this figure-ground confusion. I believe deep down this is the reason most attempts on using computers to help architects design focusses on the built-matter and ignores spaces. There is an unstated hope that the visual examination of the drawing will give cues to the architect on the spaces in that project. This approach has been taken because it is impossible to leave a computer in an ambivalent state: one where the computer works on the "figure" at one point and later it has to reverse its attention and allow focus of what was earlier the "ground"
One crude way for a drawing to speak about both the built matter as well as the space would be to delineate the spaces redundantly after having drawn out the walls. So one not only would have to draw the four walls of a room, but insert a rectangle inside the walls to demarcate the space within. However this is a very error-prone approach. If one were to later shift the walls, and then forget to reshape the rectangle demarcating the space, then obviously it would be an error.
Indeed, even conventional hand-drawn drawings also side-step this "figure-ground" problem by focussing only on representing the built matter. This has been the age-old tradition of drafting. It has got so ingrained in us, that it is almost second-nature for an architect to figure out the spaces within the drawing by looking at the marks on the drawing and then interpreting the spaces therein. It is very difficult to tell architects that indeed this can be error-prone. The fact that it is actually time-consuming is also sometimes very difficult to establish.
One crucial reason why it is important for the medium to know all that has been represented is so that you can get proper assistance in objectively working with your design. For example; If I am able to represent both built matter and spaces in a computer, then I could write a program that would help me perform accurate calculations without my intervention.
Let me give a more mundane example of this issue; in fact one that prompted me to make TAD an object-oriented design software.
I was very young when I started my own architectural practice. I was all of 26 years. I obviously did not have any 'body of work' or notoriety for other architects to find it attractive to join my office. What I did get were some draftspersons. They were hardworking alright but they were trained only to do technical drawings and not really get into designing or even understand what was in the design.
Before stepping into the world of computing, I attempted using conventional, popular drafting software for my work and I used to get frustrated leaving instructions for my draftsmen: I used to draft some initial plans on the drafting software but before I could fully finish it, I would get pulled into some meeting or a site visit or something else that pulled me out of my office. I would then request one of my draftsmen to complete what I had done. But when I returned, I found that quite often he would be sitting idle because he did not know what was the real-world meaning of the shapes I had drawn. Is that rectangle the master bedroom? Is the other one the kitchen? It quickly became apparent to me that if the software did not capture the entire representation; which included the meaning of the shapes, the half-drafted plan would serve very limited purpose. If the software forced the architect to look at what was on the screen, interpret it, and then give instructions to the rest of the office verbally; that is a serious bottleneck during designing.
Imagine you are using a spreadsheet, but for some reason you are forced to use only the digit "9" inside that spreadsheet. Obviously, that would be a big handicap when placing information into the spreadsheet.
Fig 2: Yes, you can create a clock using just the number 9 and some other mathematical operators. But it is indeed cumbersome
Here is a clock (Fig 2), that shows all the numbers on its faces using the symbol 9. It can be done, but it takes a lot of effort to read the clock. Now if we try to do some calculations in that spreadsheet with such a limitation, obviously we are seriously hampered.
Here is a clock (Fig 2), that shows all the numbers on its faces using the symbol 9. It can be done, but it takes a lot of effort to read the clock. Now if we try to do some calculations in that spreadsheet with such a limitation, obviously we are seriously hampered.
So the first point that I need to stress upon: An architect's conventional drawings do not capture the entire representation of a design. Drawings are mere snapshots of the design process. They dont represent everything that needs to be represented. If only one person is working on a drawing, the situation can be tolerated; but not if communication has to be established within a whole team of people -- and if that team is a dynamic "just-in-time" one then it is really frustrating. (Some author calls the working of an architect's office; a "dynamic, multi-organization" which gets formed and re-formed for each project)
Part of the reason why often conventionally architectural design is a meditative, individualistic exercise is possibly because of this issue: Much of the communication between the architect is a very subtle and personal and idiosyncratic and even private process; something that cannot be easily communicated with anyone else.
Apart from being incomplete, the shapes on a drawing do not carry with it meaningful nomenclature which can be used to objectively understand the design without errors by an onlooker.
Part of the reason why often conventionally architectural design is a meditative, individualistic exercise is possibly because of this issue: Much of the communication between the architect is a very subtle and personal and idiosyncratic and even private process; something that cannot be easily communicated with anyone else.
Apart from being incomplete, the shapes on a drawing do not carry with it meaningful nomenclature which can be used to objectively understand the design without errors by an onlooker.
I grappled with this issue of having to represent both spaces and built-matter non-redundantly. I could solve part of the problem by reversing the conventional approach where one first placed marks for the built-matter and left spaces as bye-products. Instead, in TAD, I first represent spaces and the built-matter are considered as bye-products of having drawing the spaces. For example; if I were to draw a room, I will draw two rectangles one inside the other. The inner rectangles represents the inner space, and the outer rectangle represents the volume of the entire room including the walls around the space (i.e. the silhouette of the one room building) This served me immensely, because in the initial stages of designing in my office, I was often grappling with issues dealing with space requirements (e.g. area of the room, floor-space-index consumed, etc)
I quickly realized that actually one could represent the entirety of architecture by collapsing ALL elements as various types of spaces. This led to a "taxonomy" of these spaces. I found that any architectural design can be broken down into a set of "atoms", "envelopes" and "connectors" -- three different kinds of spatial volumes which are found in every architectural design. It is the arrangement of these three types of spaces that form architecture.
Here is a brief explanation on how this taxonomy works: An "envelope" is the silhouette of a building: the shopping bag into which you place other spaces. An "atom" is simply those spaces that are typically not further sub-divided in the mind of the architect. A "connector" is any space that connects any other types of spaces. If we now place such spaces in our design, we will find that the built-matter is a boolean subtraction of the volume occupied by atoms and connectors from the volume occupied by the envelope. So here is a way by which one can talk both about spaces and built matter non-dedundantly; by enumerating the spaces within.
As this is just a narration of the history of TAD, I will not get down into explaining how this taxonomy works in detail and why this way of looking at architecture is a complete representation. A separate paper dealt with this taxonomy in detail and I presented that paper to the Indian Institute of Architects in 1991 and I got the Special award for architectural research in 1991
The name TAD stands for "The Architect's Desktop" It is my belief and conviction that we architects could evolve a complete system of practice (a "desktop") that truly helped architects work on design responsibly. The designing component of TAD is actually called "TAD Designer" but most of us using it, use the term "TAD" as a synonym for the designing module.
I also selected the word "TAD" because the word "tad" meant a "little-bit" or a "small boy" I then felt that a small change in the way we look at architecture can really help us elucidiate all the elements of a design. If you want to understand TAD, all you need to do is to simply reverse your expectations from a drawing: Place the spaces first and then let the built-matter emerge as bye-products. That is an oversimplification; but it can put you in the right direction.
I have used TAD extensively in all my projects and I have consistently found that it helps communicate among team members very accurately. It works excellently in the early stage of designing -- so much so that I have found that pencils disappeared naturally from my office. The hazy, early stages of designing are where architects traditionally use pencils. I found that in my office, we moved on to TAD quite early and it helped us move extremely fast in cutting through all the confusion of a design in the early stage.
This aspect, in fact, was put to test by Prof. Athwankar, a perception researcher at IDC (Industrial Design Centre) at IIT Bombay. He devised an experiment where he sought to find out when a person well versed with TAD moved into actually using my software. He found that the architect (Anjali Iyer who used to work for me) who was chosen to do a small design problem (which was videotaped) started using TAD very early in the design stage -- which was quite surprising for Prof. Athwankar as he normally have seen people grappling with a design using pencils, paper, etc. and started using computers only when things were quite clear -- a stage that is often reached after quite sometime. Anjali, on the other hand, started using TAD quite early as she solved the design problem
Now for the second fundamental question that was asked when designing TAD: Can we really provide answers to ALL questions that can come flooding when designing an architectural project? Traditionally, computer software are written by "software analysts" who sits with a user and extracts the points troubling the user. Some data structure and/or algorithm are then placed into the software to satisfy to help user get answers to those problems. However, what is important to realize that the problems elucidated by a user is often very temporal: The user has no choice but to narrate what happens to be troubling him as per his experience; often for the projects he has handled up to that point in time. It takes a lot of time and effort on the part of a software analyst to extract abstractions which can later be used to solve such problems generally in the software. The software analyst usually would take only a sub-set of problems that were expressed by users. Once the software is actually put to use, users often would turn up with more and more problems that were hitherto elusive; and then the software would have to go through a revision. Sometimes, a revision is not possible because earlier data-structures inside the software tends to dictate the future course of the use of the software.
Unfortunately, designing opens up a foutainhead which is constantly throwing up all kinds of issues and problems to the designer. Many of these issues come specifically for one design problem but may not exist in another one. It is impractical for a software analyst to enumerate each and every issue; and design the software and revise it continuously to cater to all of those. (If you now pause for a moment, you would realize that even drafting software goes through a large number of revisions -- now you know why)
The approach taken in TAD was very novel for the fact that it was written in 1989 ... (such an approach is quite common nowadays in many software but it was really novel when used in TAD) My solution was very elegant: I gave part of the problem of enumerating internal data-structures directly into the hands of the actual end user. As an architect starts using TAD, he can keep modifying the internal data so that it suits exactly the kind of problems that the architect is facing. I call this approach "just-in-time" modeling. So the model of data that the architect works on is actually not fitting into a template given by the programmer (in this case, me). The architect can himself/herself change the model just as he encounters issues in his project. To faciliate this, I had created a simple computer language called "ARDELA" (Architectural Design Language) which is actually nothing but a specialized object-oriented version of Prolog with certain built-in predicates to do geometry calculations.
When one works with TAD, the architect is actually silently developing parts of a big ARDELA program using the interface of TAD as an IDE (Integrated Development Environment) The architect does not realize that he is writing a software program, of course; as they are called to simply work with graphical shapes using reasonably familiar graphical commands. TAD actually creates an elegant OOPS (Object-Oriented Programming System) with classes and objects as defined using the OOPS paradigms seen in languages such as SmallTalk, Java, etc. But the fact is that all that complexity is hidden away from the architect. TAD internally places all the architect's wrok into an ARDELA program and it is that program which is available to query the design objectively, just-in-time.
Due to this 'just-in-time modeling' approach, I and my office, have been able to TAD in many different situations. TAD not only excels in early stages of designing, but it has also found use in post-facto analysis. TAD was used for two research projects carried out by IIT (Indian Institute of Technology) Bombay for modeling energy calculations. I worked on an approach called TADSIM that helps calculate heat built-up inside buildings. My co-researcher, Dr. J.K.Nayak and me published a paper on the same.
The third question; that of handling complexity in architecture, has occupied my mind for much of the last few years. I had presented a paper at Frankfurt eCAADe conference in 2007 on the same. The taxonomy used internally in TAD models architecture uses a fractal system of arrangement of spaces. A few years back, a very important and interesting book was written by Przemyslaw Prusinkiewicz and Aristid Lindenmayer, that explored fractals in botany. It was called the "The Algorithmic Beauty of Plants" They demonstrated that much of the complex plant forms can be mathematically explained without oversimplification. Today, L-Systems (The "L" is for Lindenmayer) are often used to model plants and trees. Fractals are used nowadays to understand complex natural forms and phenomena, not just in plants. Using fractals to plumb complex issues have found its place in many areas of life; from understanding stock-market movements, to predicting earthquakes, to problems found in lungs and kidneys, etc.
I now believe that fractals not only exist in the natural world, but one could use fractals to even model and understand man made forms such as architecture. The taxonomy provided inside TAD could offer one clear direction.
Use of fractals to model architecture can be one way to ensure that the complex, messy world we see in built-structures can be explored and understood without oversimplification. This is an exciting area indeed, and I see a lot of hope in solving some of the really intractable problems in architecture, urban-planning and indeed in all kinds of designs.
TAD has evidently stayed the distance over quite some years. In the meantime, a new terminology "BIM" (Building Information Modeler) has come into architects' lives. I strongly believe that much of the concepts in BIM have been silently manipulated by commercial organizations who have vested interests. I believe BIM still has not got it right because it speaks about construction issues of the built-form and not really the entire design process. An architect needs to wade through a lot of information even during the early, hazy, messy stages of designing. And I believe an approach such as TAD would help.
TAD Designer, the designing module inside TAD does have some limitations: Currently it does not have extensive geometric capabilities and that seems to detract people who want to use intriguing shapes. I believe that is just a mechanical limit because most of the programming was done by me; and I have my own limitations. Now that I have decided to open-source the development of TAD, I should be able to place all kinds of geometrical modelling capabilities into TAD without sacrificing its internal concepts.
Open-source of the internal coding of TAD is not just a curious coincidence. I believe that one need to open-source not just software, but also our own creations as designers. If the design intent of architects are to be exposed to other designers, and if others can contribute to a design as it gets evolved; I truly believe we could revolutionize designing and help create socially relevant designs.
I have been nibbling at open-sourcing architecture using TAD via a website; http://ww3.teamtad.com, It has not yet picked much momentum as I have spent very little publicising that effort. I am hoping that more and more people would join this initiative and open source both TAD as well as architectural designing itself.
In this article, I have tried to give an overview of what went into the creation of TAD and some background stories. There have been many people who have helped me think through the concepts; especially almost everyone who worked with me at my office, Sabu Francis and Associates (SFA), and a few other architects and professionals have also contributed. I am grateful to all. I've acknowledged all of them separately at my website here: http://sabufrancis.com/tadcontributors
I welcome feedback on this along with any kind of contribution to this "magnificent obsession" that has taken up much of my life.
