Don't be a plastic penguin

I get a lot of enquiries for architectural internships. Many students are either confused or highly opinionated on the kind of internships they need.  So this note is for them. Partly, this also applies to other design fields such as software design, product design and so on — in any situation where there is “architecting” going on.

To become a good architect one need to be good at using both sides of the brain. An architect needs to grapple both with empirical knowledge as well as abstractions. Our field is very unusual in this requirement: most fields can work by gravitating towards one or the other but usually not both.

Those interested in pure sciences and maths for example need to worry only about rational thinking using abstractions. They do not really need much of empirical knowledge. They can introspect and work out internal contradictions in their theories and get productive work done; with no real connection to the outside empirical world. That is how Andrew Wiles sat through for over seven years working practically in secrecy to prove the much talked about Fermat's last theorem. Simon Singh wrote a fascinating book about it. http://simonsingh.net/books/fermats-last-theorem/who-is-andrew-wiles/  The advantage of abstract rational thinking is that knowledge can be quickly built up because an internal abstract framework is usually available on which things can be pegged.

Then there are fields such as medicine where much of the knowledge is empirical. Doctors can become better and better as they get more and more experience; as they absorb more and more information from real world situations and stitch them up using empirical, heuristic techniques in their mind. Of course, the process of building empirical knowledge is fraught with danger. I know of several doctors who have remained stupid and cannot really stitch up empirical knowledge -- even when they get experience. 

It is not fully their fault: Building up of empirical knowledge is not amenable to an internal structure on which the knowledge can be built. A swallow does not make a summer, so making patterns out of experience requires a lot of humanity and depth which some people lack; especially those who cannot look beyond their work into other aspects of life. Also, if a doctor does not really encounter a difficult case, he would remain ignorant of the salient aspects of the case for years. I will again come to this point later on when I discuss empirical knowledge in architecture

To reiterate: Architects need to do both kind of thinking. We need to have abstractions. After all, no such project existed when an architect is given a plot to design. The architect is forced to conjure up one. The architect then has go all the way to empirical knowledge too. Such as, select the appropriate brick-bond for the external wall to reduce leakage, etc; which requires practical experience in that area. A discerning, sensitive architect would be considered quite mad by those around him or her -- because s/he would be dancing around in many areas in his head.  In the initial years the thoughts of such architects tend to overwhelm the audience with the areas of concern: there are just too many an architect is sensitized to. 

Young architects getting hitched to non-architects need to take care. A newly wed architect can easily bore his non-architect mate as he gets into lot of details which his mate may regard as unnecessary. The famous architect, Mies Van Der Rohe had said “God is in the details” and many architects understand that just too well. They happily get into details where others fear to tread; and in the process, lose the audience.

So now the question of internships: In any architect's life, an internship is very crucial — because that is the time the  empirical side of the architects brain start getting inputs and gets built up. As noted before, building empirical knowledge is quite tough. There is no pre-existing framework. It is easy to misunderstand reality as one can easily keep working on some part of the real world while ignoring more important parts. Nicholas Taleb captured part of this issue in his books “Fooled by randomness” and “Black Swan” — though in those books the subject was not architecture or design.

It is possible to be misled when choosing the office where a student can do an internship. Some architects “pre-select” the area of the work they want to be involved in. Some professional architect's eye may be on a coffee table magazine or some award; and therefore may never get into those areas of practice which are really difficult and messy. I would never work with such architects or recommend them for internships. 

One of the saddest aspect of architecture is that those who really need architects cannot afford them, and those who can afford architects can easily design and construct their built-environments without the help of any architect: The rich can easily build, demolish, and re-build till they get their environment right. So many architects unfortunately are working on the wrong problem — the real problems out in the world are not really the ones that many practising architects end up solving. It is not that cute little farm house which won an award. It is not the high end interior for a corporate office. It is often not even an office building that is now internationally recognised. Architects nibble at some 1% of the real design problems in the world.

So, the young architectural student out on an internship need to understand the challenges worth fighting for. Learn to ask the hard questions early in life. As empirical knowledge does not have a framework, the only substitute is to get deeply involved in many aspects of life: art, culture, ethics, philosophy, economics, psychology, sociology and so on. The only real way to build up empirical knowledge is to get exposed to as many facets of life as possible. Here is a nice article which explains why it is important to go after the right "pain" in one's life: http://www.huffingtonpost.com/mark-manson/the-most-important-question_b_4269161.html

Pick a small to medium size architectural practice where the architects are deeply involved in a lot of such questions concerning life — not just the architecture being designed at that point in time. If one or more architects in that office have done some theoretical work or teaching, then the chances are that could be a good office to work for. If I was to do an internship, I would shy away from “brand” architects as most likely I would only sit in one corner doing some minor modification of some drawing that nobody is interested in. 

Internship should be a “two-way” process. Unfortunately, many students get into a pre-school “learning” mode with their mouths open like silly plastic penguins one finds all over India which is a lame substitute for dust-bins, often with the words “use me” painted on them. Yes, such students would get used and only rubbish would be placed into their mouths. A good intern should try to be in a position of influence (or at least gravitate towards that) where he or she has the freedom to exchange knowledge and indulge in healthy debates of life in that office. Obviously those debates must be based on sound background knowledge; and not just emotionally charged opinions. 

If you want a quick summary: Internship in offices with noisy, healthy debates are the ones I would recommend.

This note also applies to fields such as software design; which is traditionally not regarded as “architecture” I have seen far too many silly software and websites that end up solving some non-essential part of life. There too, the designer has not got a proper grip on the empirical world around him/her.

All the best. May all architecture students bloom to become wonderful architects working on real problems

The Rot in the Column

This was originally written in a discussion group here: https://groups.google.com/forum/#!topic/cbsarch/GzNxTwjYJ-k

When we sift the debris from any building collapse, there is one body that is never recovered: She is our muse. Her name is architecture. It is our collective shame that we have never been able to peel the layers of rot in the column of systems that go towards holding up architecture in India. I'll make a small attempt here. I hope this is not regarded as finger pointing or even sanctimony. Even if I may come close. Usually, I do not indulge in generalizations and reifications. However there are some topics that can be discussed in a general manner, and I believe this to be one.

We all see architecture as it exists out there in the real world. Architecture is experience. Many of us think that is all there is to the subject. Even architects. But architecture happening in the real world should ideally be an outcome of careful thought processes, much of which are never discussed or systematized by architects and other consultants. Like an iceberg that will show only a small percentage of its volume above the sea, there is quite a lot which is hidden. I've always maintained that the product of architecture comes out of the processes of design. The product is what we see out there...but the processes are sadly hidden; locked inside architects offices. Unfortunately, amnesia sets in when processes are allowed to be hidden, and quite often architects simply forgets to carry out the required processes. How many of us really carry out a climatology analysis or site analysis or user-behaviour study for a project before working out its design? In fact, how many of us leave our project design in any analysable form for future introspection when things start collapsing?

In fact, many architects don't even recognize that there are processes that needs to be systematized. They just take out their sketch books and furiously draw out the final forms that the iceberg need to take shape. They are so eager to get the project into the real world; that the careful checking of what ought to pop-up above the ground is never done.

At one conference, a famous architect was proudly claiming that he got his pear shaped design for a project when doodling on a pad during a flight. Flight of imagination? It was so romantic! I remember all the 2000 students attending the conference giving a thunderous applause on hearing that architect's passionate explanation. Today, that project is out there in the tropics called India. And people working inside that building are huddled at  computer monitors within umbrellas. Umbrellas? Why? Because the pear shaped building has so much glass, that the glare from outside prevents normal viewing of a computer monitor!

With this kind of trend-setters that exists in our field, it has become very easy for non-architects to come into the profession and get into some nooks and crannies of architectural practice. Many architects often don't take up such projects or are ousted out by the unscrupulous. So we have a huge set of "interior decorators" and "interior designers" who are not trained in understanding the processes behind the product called architecture. And as architects; we have never been able to get such untrained quacks in line because many of our own learned and recognized peers do the same thing.  These quacks happily play around with the internal columns of buildings thinking that it is quite similar to making quick sketches on a flight. With disastrous consequences.

Why is it that architects abhor the processes of design?  For understanding that, we need to look into architectural education. That layer of the column has quite some rot. There is a rot in  both teaching and learning.

It actually does not start at the level of the architecture college, but just before it. There is this absurd career oriented demands; that our society place on our kids. Anxious parents and their kids crowd in front of mark lists anxiously looking at how they "performed". As if there was a circus over there. The result is that budding architects are so marks-oriented that they forget that marks are only a bye product of their knowledge. Instead, marks become an end product by itself. Later on in their career, the same architects substitute "money" for "marks".

If only they had clarified the concepts, then these kids would have been able to look deeper into the water later on in their lives. In the pecking order of our society, the profession of architecture does not score high. Everyone knows the kind of dirty people who are involved in it, and overprotective parents would not want to place their dear children in such company. There are other reasons too: The salary earned by fresh graduates is very low, etc. So everyone is clamouring to become an engineer or a doctor. Nowadays "management" (whatever that means) is also a good career option. But not architecture. Even if the child can grow up to an important architect, she has no choice: She is made to believe that architecture as a subject is not a profession "comparable" to that of engineering or medicine.

As a teacher, I have had first hand experience  interacting with kids who came into architecture simply because they did not get engineering or medicine. They just do not have a love for it. So what do they do? Some actually develop the love as they grow out of their adolescence; only to be thwarted and insulted by bad teachers and even worse, they are pulled down by really bad management who is out there only to fleece and play politics.

But some students go onto develop, what is colloquially known as, a "crush" for architecture. There is no maturity in that love. Many students are affected by deep sense of inadequacy. They dress up their liking for architecture with a veneer of false bravado. They sprinkle their talk with arbitrary definitions. They huddle amongst their own peers and their intellectual capability sink to the lowest level within their peer group; usually the most vociferous. Some speak in soft cultivated "cultured" tones, as if just sounding knowledgeable is all that is needed. Some even quote from books without understanding that much of those books themselves ought to be hurled through the fire of critical thought. I find that much of architecture students either aimless or aping. As nature abhors vacuum, the intellectual space of many students is invaded by false intellects who do verbal antics ... and  students often lap them up.

Much of the antics are done by badly trained teachers. They don't do any reading of their own, and even if they do; they have allowed the faculty of critical thought to rust. They come to colleges for varied reasons... for most, it is a stop-gap arrangement. I have found very few professors who are genuinely love teaching. And the reason is simple: I believe one can only be in love with teaching only when one is in love with learning. Only then can one empathize with the state of the students. Let me not make the mistake of indulging in bad thinking here: Of course I cannot generalize. Of course, there are genuine teachers, and genuine students too. But the odds due to the rot in the system are so badly stacked against them; that they are very few and far in between.

I have encountered some surprising examples of bad teaching. I was taken aback by teachers who had no clue how the sun moved across the sky dome ... their knowledge of climate was so appalling. I used to snicker at teachers who could not formulate the right logic to explain the processes of architecture. I was dumbfounded at the kind of bombastic statements made by teachers who dramatically explained architecture as if it is something that can evolve out of poorly defined philosophies. Leaving things half-explained, in a mystical manner, was actually considered "hep". I used to think that students would object but when I turned back to look at the class, I was stunned. They were very impressed with such talk of these emperors' new clothes. My points were difficult to grasp and I left many students confused. I sadly realized that personalities ruled education. The depth of character or knowledge do not mean much to a hormonally influenced adolescent.

A knowledgeable surgeon, Dr. Nobhojit Roy, spoke at a congregation of architects and students, and he had a surgically incisive point to make: "When we open up a patient for surgery, we often have an insurmountable task: After all, we don't have an endless supply of raw-material. In fact, we don't have any raw material! Whatever nature has given that is there inside that body... and some of that now gone bad and needs repair. So what do we do? We wrack our brain, and do our best. Fortunately, our best is sufficient and more often than not we get the job right. That happens because we are damn meticulous in whatever little we can control. We don't let it go out of hand. We are rigorous and thorough. Now look at your own field: Architecture. You can start with your imagination. Nobody can stop that. You can pick out and invent and use any raw material. But then what do you end up do? Ape everyone else or the foreigners! And then do a bad job of it. It is a shame that you can't even be original. That is possibly because you are not rigorous enough"

When he was saying that, I was looking at the faces of architects and students. I am sure some of them genuinely thought that they were doing original stuff. But this was like a sock on their jaw. Originality in architecture does not mean pretending to be original... If you need originality, you need rigour.  You can't get the former without the latter.

The rot in education goes even higher up, into how education of architecture is monitored and licensed: There is this preponderance towards separate "colleges" of architecture. These are colleges are like hermaphrodites on separate islands of knowledge; insulated from others, mating with itself and producing mutant unworkable knowledge. And that sense of false bravado that I spoke about keeps the spirit and joviality alive in these colleges. It is important for such students to proclaim that they simply hate mathematics and science. Some of them go on to dictate hard working structural engineers and end up making impractical structures. Some of those structures eventually collapse.

I have interacted with students on Orkut and other Internet forums, and I find that there is this special identity that they achieve when they proclaim their artistic side of their life. But I have often implored why should the artistic side of a person be at the loss of clear reason? Einstein was a reasonably good violinist. Albrecht Durer was a mathematician by training. Richard Feynman, the Nobel prize physicist, was very good at sketching and playing the bongos. The list is quite endless, actually. But such arguments often fall on deaf ears.

Many students don't even rise up to the occasion when doing their thesis. I get endless requests on the net from students asking for "ideas" for their thesis. Even a cursory peep into a dictionary would indicate that a thesis needs to be original. It is that last chance for students to do a thorough and rigorous interpretation of architecture. No wonder, in India, we don't have much original contribution to the body of theoretical knowledge in architecture. And many students consciously decide to miss it, because they are caught up in producing work which they think will please the jury! These students, who by now ought to have been adults, are behaving like school kids wanting their teachers to hold them by their little finger to take them to the loo.

The students cannot be blamed entirely. In many colleges, there are strict rules regarding the kind of thesis that a student can do. They are not encouraged to talk about processes. "Where is the design? Where is the design?" is the constant refrain from professors. Thesis MUST end in a design, they have been forced to believe. So students take a simple detour: They think first about the design and invent all kind of hogwash to write in their report which substitutes the processes of a design.

Moving to the next layer of rot: practice of architecture. Students who are ill trained, who never really liked the subject for all its complexity, who grew up from adolescence into adulthood and learnt some bits and pieces of truths along with an enormous amount of misunderstandings... students who were forced to think about the product instead of the processes of architecture ... all such students land up on the door of architects who themselves were all of that once upon a time. I have always made a distinction between one who has a formal education and a learned person. Those who are only formally educated often don't grow up holistically. Our marks-driven syllabi often get a student to get formal education, but all the other qualities that uplifts the character of person to become a "learned one" are often missing. For e.g., many fresh graduates are not good thinkers or good listeners. Quite a few of them end up as sycophants, as they were so used to saying "yes sir" to diplomatically solve problems with their teachers.

Another speaker (from the US) who had come to talk to practising architects on business mathematics and profitability was amazed at the muddled thinking among practising architects. He attributed it to one simple reason: "In India, we have always believed that people should be gainfully employed as soon as possible. Whereas the emphasis in many other countries is first on getting the student's thinking correct. Money will come as a bye-product of that thinking but sadly nobody recognizes that to be true here" Once again, a product v/s process confusion. Fresh graduates yearn so much for money and recognition that they don't realize that they are falling prey to the darker side of their character (like petty jealousies and unfair comparisons) when they rebel against their employers to start their own practices. Thus, India is full of half-baked practices. Most of them with one (or a small group) of personalities at the top of a pyramid. I can count the number of non-personality driven architectural practices in India on the fingers of my left hand.

And what about the rot in a well settled practice? I feel we don't emphasize the word "practice" sufficiently enough. It means something that ought to be repeated. And with every repetition, one needs to remove something that was bad and introduce something which is better. That can only happen if we get the theories that go into the workings right. But those theories must be constantly rectified and enhanced as new knowledge come into our lives. After all, architecture happens at the meeting point of multiple streams of knowledge. Research; unfortunately, is regarded as a big unnecessary bore. After all, architects in India gets this license to practice for life. So what is the point of it anyway? With the result, architects get their "researched" information about building materials, climate, etc. from unscrupulous building material manufacturer's representatives who come into offices with "knowledge" packaged into slick brochures.

And the very few architects who do want to contribute to theories in architecture are often seen indulging in their own petty jealousies in conferences, workshops and competitions. In fact, as researchers in architecture in India are quite a rarity, those who are here in India often attempt the corner the field to themselves. The people available for proper peer-reviewing are spread very thinly across the country. When a paper is sent for a blind review, it is very easy for a reviewer to do be swayed by his/her personal opinion of the person rather than the contents that was sent for review. There is not a single peer reviewed journal of architecture in India, to the best of my knowledge.

I believe that doing proper research in India, is really tough. Especially in the context of a practice. In my practice; it has been extremely difficult, if not impossible, to explain to my stand to my staff. My surprised employees who would look at me strangely when I claim that yes it makes a lot of sense for an architect to understand computing ... Because in these complicated times we need to parametrize many things and do a lot of computing. Those can no longer be done manually. So most of these employees either leave on their own or are retrenched. And sadly, my office can't afford to employ any more of such architects. Because neither do these architects have the kind of skills my office needs nor do they have the correct attitude towards learning.

I have not spoken about the rot that affects our muse from the world outside us: The bad, untrained contractors who don't know the difference from a column and a beam. The building authorities who are clueless about the information they should ask from architects -- they ask only for the bare minimum information which satisfies their current requirements. It is dreadful to think of the kind of information that would be made available by these authorities, say, in case of some large disaster like an earthquake or a massive fire or an epidemic. Then there are the untrained builders who can't neither understand economics nor construction ... the list is quite large.

Sadly, I still believe that we architects play a major part in influencing the members of that list: If we were to show to the world outside that we are worthy of respect and that we have substantial knowledge that can be profitable to them, then maybe they will take us into confidence when formulating their own strategies. I am yet to see one workshop or conference, where builders, contractors, architects, building material manufacturers, economists, building authorities sitting together to discuss what is meant by "profits" in our industry.

I must admit that I was part of all this rot at sometime in my career, in some form or the other. Mostly, as one who was affected by it. Yet when I look back I was still contributing to it because I was finding reasons not to tackle the rot. Fortunately, at a personal level, I was able to extricate myself to some extent . Hopefully I have grown wise to admit my mistakes. What I ended up doing (or was forced to do so... take your pick) is to walk out of confrontations and situations. But I think that is not a complete solution... so I cannot be placed above blame either. Part of the challenge is to be right there in the stinking marshes of bad architectural practice and attempt to do something good. Trying to pre-determine the kind of practice one ought to do is actually quite selfish. If one is a professional, one needs to be professional in all contexts: a professional needs to do his/her work facing it all.

I don't think anyone can be placed above blame. We all need to do some deep introspection and work out some cooperative systems to keep the rot at bay or at least keep it to a minimum. We need to do that all levels of the "column" that supports architecture in India. In education. In practice. In research. In monitoring and licensing. In approvals of buildings. In construction. In building economics. In fighting quackery. Architecture is collapsing in India all around us. Mainly due to shame

The circle that danced: The story of Pi

Madhava was a troubled man. He mumbled to himself. He was pacing up and down his house muttering angrily. Something was eluding this Malyalee that nobody understood.  (People from the state of Kerala, in South India are often called "Malyalees") The fact that he mumbled to himself was quite well known in that household. All the children in that traditional "naal-kettu" (house with a courtyard) sometimes giggled in the background at this eccentricity. But not loudly. For Madhava can suddenly stop his pacing and give that angry glare of his, another well-know trait, which can strike fear in any child. 

Every once in a while, people would see him suddenly dart into his room. Nobody knew what he really did there, because he was quite an intense, private person who  had resigned himself to the fact that nobody understood him. Only a few trusted and loyal students, knew what he did there. They were privy to his work: he would scribble some notes on "ola" (coconut leaf) which was the medium for writing in ancient Kerala. He was a mathematician and an astronomer; terms that the ancient people had not fully understood or defined.

Everything keeps moving in Kerala. Every leaf trembles. Each and every branch sways. In Kerala, there is always movement all around. It was Nature's way of teaching the concept of iteration (cyclic repetition and re-examination) to this mathematician, Madhava; who often used  such a device in his work. However, during sunsets, the effervescence due to these natural iterations dies down a little bit.

The quiet hush of a Kerala twilight comes in quickly in the evening. The dappled shadows of the gently swaying trees that shrouded the horizon soon morphs into darkness. It is almost akin to the sudden sunset in a valley: For the thick greenery which enveloped every horizon around any given space in Kerala was akin to being inside a valley; a valley of thick, ever-moving greenery.

Madhava paused his pacing as he saw the silhouetted giggling children prancing in the traditional Kerala house courtyard that evening.

A child came with a lamp. "Deepam, Deepam, Deepam"  ... she chanted as she carefully manoeuvred  into the courtyard, with one palm gently shielding the flickering flame on the lamp from the evening breeze.

That traditional chant  "lamp, lamp, lamp ... " echoed around the house. 

It was a warning to  the demons: Darkness will not conquer that household. The lamp will now serve the purpose of throwing light into that house making the dusk really beautiful.

The child kept the lamp right at the centre of the courtyard. Seeing this, all the cousins came rushing towards it; throwing long shadows all around the courtyard. There were many children in that large household. They were a joint family ... As if on cue, the children formed a circle around the lamp and bowed respectfully to the lamp, moving together in rhythm. They did this most evenings, as a ritual.

That evening, however, was different. 

The children's excitement could not be contained. For just a few days back the festival of Onam had just ended and they were all mesmerised by a dance they had seen the women-folk performing. Onam was the festival where the much beloved mythical Kerala king, Mahabali is said to visit every household in Kerala. Malyalees believed that Mahabali was so close to them that he wanted to ensure that they were doing well at least once a year. That was Onam. The legend of Mahabali is yet another story, which I will not get into as that would be a digression from this quaint little story that unfolded that evening.

The children had seen many ladies perform the traditional "kai kotti kalli" (Literal translation: a play involving clapping of hands) during the festival. And they had confabulated among themselves to perform that dance that evening. The dance started with the ladies gathering in a circle around a lamp, gracefully stepping back to form a circle; and dancing around the lamp in a curious rhythmic fashion.

That is what the children did. They started this dance. As there were no photographers around to capture that event that day, here is the video from YouTube which shows such a dance performed by ladies. The tradition continues even today by many women-folk of Kerala, especially during Onam.

Madhava stood transfixed as he witnessed the little children dancing. The children had learnt every step of the dance, and he saw them stepping a few steps in one direction (clockwise) around the lamp, and then turn back and step in the opposite direction (counter-clockwise) Every now and then they would clap their hands in rhythm to the song they were singing. The clapping gave a momentary pause in the dance so that every dancer could correct herself and catch up, in case there were errors. Every once in a while, they would step towards the centre of the circle, the lamp; and then step back once again to resume the iterations around the lamp.

If one could only capture the smile that slowly occupied Madhava's stern face... It would have captured that very moment when Madhava got enlightened. His smile was brighter than the lamp in the courtyard. He chuckled as he ran into his room to scribble some more notes into his "ola"

The original "ola" written by Madhava was lost in time. Luckily, some of the students had preserved the work in their own notes. Subsequently, many scholars pored over Madhava's work and they have been wonderstruck for quite sometime now. He was possibly the first mathematician who discovered a remarkably accurate method to calculate the value of Pi.  

In Madhava's text, they saw a series written down and they were mystified why one term was a negative -- going in one direction, and the other one was a positive one -- going in the other direction, and the entire series kept stepping rhythmically in that fashion into an infinite series. They were most mystified by the fact that once in a while, the series corrected itself; eventually rendering the value of Pi with amazing accuracy. 

Many centuries later; something called the Internet happened in this world and a website on the Internet gave the essence of these scholars' interpretation of Madhava's work. I now quote the appropriate section of Wikipedia verbatim below. 

It seems they are still not sure how Madhava managed to write the equation for Pi. Moreover, they still are not sure how Madhava got the correction terms. Maybe if they were present that evening at Madhava's household witnessing the little children dance in the courtyard, the Wikipedia entry would have been different.

Start of quote:

Madhava's work on the value of π is cited in the Mahajyānayana prakāra ("Methods for the great sines"). While some scholars such as Sarma feel that this book may have been composed by Madhava himself, it is more likely the work of a 16th century successor. This text attributes most of the expansions to Madhava, and gives the following infinite series expansion of π, now known as the Madhava-Leibniz series:

which he obtained from the power series expansion of the arc-tangent function. However, what is most impressive is that he also gave a correction term, R_n, for the error after computing the sum up to n terms. Madhava gave three forms of R_n which improved the approximation,namely

R_n = 1/(4n), or

R_n = n/ (4n² + 1), or

R_n = (n² + 1) / (4n³ + 5n).

where the third correction leads to highly accurate computations of π.

It is not clear how Madhava might have found these correction terms.The most convincing is that they come as the first three convergents of a continued fraction which can itself be derived from the standard Indian approximation to π namely 62832/20000 (for the original 5th c. computation, see Aryabhata).

He also gave a more rapidly converging series by transforming the original infinite series of π, obtaining the infinite series

By using the first 21 terms to compute an approximation of π, he obtains a value correct to 11 decimal places (3.14159265359). The value of 3.1415926535898, correct to 13 decimals, is sometimes attributed to Madhava, but may be due to one of his followers. These were the most accurate approximations of π given since the 5th century

The text Sadratnamala, usually considered as prior to Madhava, appears to give the astonishingly accurate value of π =3.14159265358979324 (correct to 17 decimal places). Based on this, R. Gupta has argued that this text may also have been composed by Madhava.

The "Why" of BIM

I believe one needs to ask some deep "why" questions which will lay down the objectives of open source BIM. I subscribe to the thought explained by Simon Sinek in a TED presentation: http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html

A lot of useful innovations have happened because leaders asked and answered the question "Why" first before answering questions such as "How" and "What"(Simon Sinek explains not only in the context of business but also in social movements, such as Martin Luther King's points...)

So first of all, I recommend we really get into the question "Why".  This article is based on some discussions that is happening currently in a Google group in India, exploring open-source BIM.

Why do we need Building Information Modelers and why is it important to think of it once again ... not just take off from what is currently existing. (To be graceful to what is existing: We could do our exercise and later on realize that current standards are useful, but we need to carefully tick-off on each of the following points before doing that)

1. Because we need to support the entire spectrum from concept formation all the way to construction

Designing is a spectrum. It starts hazily from an architect's mind and proceeds towards final, crisp stage. Ideally, BIM should cover the entire spectrum. There has been some attempt from the West to computerize early stage designing. (e.g. SEED ) but those did not take off. Currently, it is taken as granted that BIM is done towards the final stage.

No doubt, there are companies that have tried to use BIM in earlier stages too ... and some commercial organizations confuse us further by claiming that things like massing, etc. can also be done using BIM for helping in the early stages. But the theories behind that approach need to be investigated. What we must realize is that information management is necessary at all stages of designing and all the way into construction. It is not just help in "visualizations of massing"

Earlier the information is handled; better it would be for design. Currently, it is assumed that all the messy, hazy stuff that happens during the initial design stage is best done by architects using their favorite methods ... and later it can be transferred to computers. One of the prime reasons why many architects ( especially experienced ones) do not take to computerization and BIM is because they see a disconnect between the early stage and the final stages of design. Currently the situation is: Early stage = NO computerization. Final stage = Computerization. Ideally, what I have been striving towards for last 20+ years is to look for computerization as a help, not just a thing to be used entirely, who can sit side-by-side with an architect and later on engineers and other consultants EVERY STEP OF THE WAY.

2. Because we need to record design intention, not just the design

Many think of architecture as the way it is finally seen out in the real world. That is just the tip of the ice-berg. But beneath the surface, there has been a lot of decisions that went to make the building what it is. What is also needed is to record all the intent, nebulous qualitative attributes, decisions that were forced due to management practices, etc. The reason this is important because architecture can be put to many unusual uses and situations. A building may get converted later on its lifetime. A warehouse can become a clubhouse. An award winning building may later on be found to have very serious problems later on and when the problems surfaced, there would be serious people wanting to investigate what went wrong so that the same causes do not surface in other buildings.

The most dramatic example of such a situation was what happened before the collapse of the World Trade Towers. The context was never experienced before, and so nobody could really predict how the buiding would perform in that crisis. Sadly, this was the SECOND project of the same architect which had seen dramatic failure. The first one, the Pruitt-Igoe housing complex, was equally dramatic but it was demolished not by terrorist attack  but by the state who found that the award winning project of that architect was almost completely useless. Finally it was dynamited. As per Charles Jencks, architecture historian, it marked the day when "modern architecture died". Pruitt-Igoe is a famous study that is spoken among architecture researchers but not much outside. http://en.wikipedia.org/wiki/Pruitt%E2%80%93Igoe

This issue can be seen in earthquake relief, emergency situations, fires, etc. Sometimes one may need to model movement of people through the building. There has been many cases where people move en-masse towards the wrong exit in case of a fire. Recording design intentions can be very useful in such a case, because one can assess what kind of management directives and steps should be supported and what should not be. For e.g. An irritating client could insist on closing a window opening (it has happened with me) and later on it was found that for the lack of that window, the apartment did not perform correctly climatalogically

3. Because we need to save time

Saving time happens on multiple levels. One is saving the mechanical drudgery of making drawings, models, printing etc. That gets saved when there is a single BIM model to refer to. But more subtle is the saving of time when the management of the design process is properly supported. To give an analogy: Calculators did save time for calculations, but when the financial planner got a spreadsheet, he did not get just some calculator with additional capabilities but it opened up a lot of "what-if" calculations that the planner could now do and then use those creatively. Much, much more time gets saved. The approach to BIM therefore should NOT be just "okay, we need to have a very good way to put all the geometric information together, holistically" Yes, that is one goal. That has been somewhat achieved by current BIM but that is not sufficient

4. Because we need to respect the end user as contributors to the model

As per Stephen Covey: "Problems are solved twice. Once in the mind and once in the real world" Modeling is NOT the whole sole property of people like me and others developing BIM, the people who make the proposal. But a model should ideally be open to receiving inputs, sometimes even at the last moment, from the actual user. This trend can be seen in many other data standards too. For example; when Tim Berners Lee proposed the HTML standard it was a "hand-me-down" set of data constructs that the end user had no choice but to use. But that approach is changing. Today, HTML 5, XML allow for new elements to be inserted by the user as he deemed fit, that follows meta-rules.

If you look at BIM standards carefully, you will notice that much of it is still archaic data-structure approaches of yesteryear. (I can give references and my insights in this later) I suspect, much of the current BIM standard has been manipulated so that the commercial organizations that helped create them could ensure that their own proprietary software continue to get traction

5. Because we should respect the D-R-Y principle

DRY = "Don't Repeat Yourself" is a well established concept in computing. Any form of redundancy that comes into data structures can wreak havoc. DRY was a term I think invented by the Ruby-on-rails people which essentially mean the same thing. However what is "repetition"?  There are obvious ones and unobvious ones. But opinions vary which is which. A piece of data which is repeated to me; to someone else it may look quite harmless and done just to get some specific job done and therefore can be accepted. For e.g. Using construction lines to draw other elements is a known practice among draftspersons.  Often the construction lines are left behind quite harmlessly. It may be okay when we speak about drawings but when it comes to modeling, if some object was created only for creating some other objects (say a CSG model) and then if that is left behind it can confuse others using the data.

In architecture models, there is one major issues that many BIM and CAD programs do not think is very critical: That is repetition of "spatial volumes" For  e.g. If I draw 4 walls that enclose a room to the visual eye, there is a space that is enclosed but then it is not measurable as the data-structure cannnot glean that out. So people are instructed to happily insert another volume that denotes the space -- and architects do that without knowing the implication --- that is very subtle redundancy there and that can lead to, and often does, very serious problems during automated objective analysis of the data. For e.g. If the data is to be queried for the area of the room inside, it may initially give the right figure ... but when, during some modifications, the walls are moved around (which also should imply that the object denoting the space of the room should also be modifed- -- but many time it may not get modified due to oversight) then we have a very serious problem because the room will still reveal the old area and not the new one after the walls were shifted

6. Because we should also respect all kinds of design processes and thinking

When designing, an architect often starts delineating the spaces in the early stage of design. Usually. But not always. For e.g. as an architect I often work in that way. But there are architects who may work on the built-forms earlier... or it could be a mix. Even with spaces, there is no really rigid rule which kind of space need to be represented first. I had adopted an unusual approach for a hill-resort I was designing in Munnar, Kerala in India. When I went to the site, I first located the various views that I wanted to capture -- so effectively, I was first working out the potential locations for the window openings rather than the rooms to which those openings would go. I had to have a modeling system that allowed me that -- lots of windows hanging around inside my early model; without knowing which rooms those windows would eventually belong to. Later on, when I figured out what are the rooms that resort needed, I arranged the rooms to take advantage of the previously located windows.'

Current BIM standards are extremely rigid on the way data is arranged. For e.g. In most BIM, I doubt whether one could create an opening without first creating the wall into which the opening is placed. That approach looks logical. People sometimes wonder, how can one construct an opening if there was no wall around it? That is right when construction is concerned; but when an architect wants to start thinking about a design he may want to first think of the openings and then the walls.

There is a much-bandied term called "ill-formed" objects in CAD and BIM (objects that geometrically could be constructed on the screen but cannot exist in the real world)  There have been data-structure approaches such as the "split-edge" data structure proposed by Yehuda Kalay and others from Berkeley which tries to put all the data in a non-redundant manner into the computer. But then I found it too rigid and not respecting the need for architects to sometimes think non-linearly, or out of sequence. That is why I find that current BIM is more construction oriented instead of design oriented

7. Because we need to incorporate concepts that have found to work in other areas such as management, computer programming etc

Today, the "agile" process of software development is very well known and respected. Many programs are designed using those principles. I believe that approach (i.e. the spiral-development approach using Agile) is very useful in designing and the data standards should help achieve that. In an agile process, the design is quickly developed, criticized, tested and then dismantled if so required, so that the next design cycle can be quickly started. What happens in traditional CAD and BIM is that the process starts gathering a lot of complicated stuff as the representation proceeds. An architect finds it extremely difficult to dismantle something that he has modeled just so that he can re-examine the holistic again in another agile cycle. Conventional CAD/BIM is not very respectful of the agile process

Another concept that I would love to see in BIM is "just-in-time-designing" which is derived from "just-in-time manufacturing". In JIT manufacturing, there is a lot of advantages because inventory costs can be very low, and errors removed fast. Some JIT processes are now seen in computing too (JIT compilers, for example) I strongly believe that just-in-time techniques should be available to architects too : Often the decisions that go towards making a really good design come and "click" into place at the very last moment (i.e. "just-in-time") The data standard should be respecting such a need. Again, this means the data should be very light and should NOT pick up too many heaviness as the design representation progresses

The story of TAD

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.

I did not get into computers intentionally. I often claim that I was walking on a road minding my own business when I fell through a magical open manhole which pulled me into the world of computing. Myths aside; I remember almost the day when that happened. I was leaving architect Hafeez Contractor where I was working as an associate. I was not in conflict with Hafeez's office. Which made my exit more peculiar. Hafeez did not want me to go and he even had his friend and structural engineer; Kamal Hadkar, to intervene. I remember chatting with Kamal for hours at his office when I was exiting Hafeez. And along with Hafeez, Kamal is one person I respect a lot: A very innovative structural engineer; one of the stalwarts in his field who could keep pace with Hafeez's imagination. Kamal and his office had done several complex projects of the time: The new Stock Exchange building ('Dalal Towers') at Mumbai, with its amazing spiral staircase, shell shaped canopy...

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.

Fig 1: Figure-ground confusion: Our attention is drawn sometimes to the "vase" formed by the white portion, sometimes it is drawn to the profiles of two faces.

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.

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.

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.