The what and why of TAD

This note should help those who are interested in holding a workshop on TAD and others who are sitting on a fence, wondering what is this all about.

TAD stands for “The architects desktop”. It is a designing system that respects the way architects design.

The starting points for design are many.

One could start designing say keeping the amount of areas in mind as the main priority. Some want to start design keeping the evolving 3D forms in mind.

I once started a resort design where the important criteria I wanted to keep were the views of the surrounding mountains. So The first thing I inserted into my evolving model were just openings - which were magically suspended in the air as my office started the design.

In computer science they call such flexible approach as “loosely coupled” For tightly coupled means the software designer dictates the hand of the whoever who is using the software. Tightly coupled software insists that the user must behave in a particular way.

Loosely coupled software are not seen much because writing such software is hard. After all what should the software developer do if he doesn’t know how exactly the user would proceed.

TAD evolved out of a messy architectural practice - one where the architect was just a pawn in the midst of the marshes. It was impossible to predict what would be the diktat imposed on any project so it was important to cater to any approach.

TAD is the only early stage design system in the world and one of the first attempt at BIM. Though BIM (Building Information Modeling) is a term promoted by a commercial organisation (Autodesk) theoreticians have been talking about the need to provide information in an architectural model since the seventies.

Information need not be just visual. Architects indeed have many objective criteria that are non visual and they too are important ingredients of the information that need to be assessed.

This loosely coupled situation was faced in the messy architectural practice that gave birth to TAD. It was at Navi Mumbai, the largest city in the world (during those days) that was furiously evolving from the marshes.

TAD handles any kind of information that an architect may need to insert into his/her model right thru the design process right from the early stages onward. Here too TAD allows loose coupling. There is no hard and fast rule on the kind of information that it needs to handle. You can actually invent your own term for some property and insert it into TAD just in time.

Though TAD is labelled as an early stage design system it actually handles designing from very early stages onward all the way to even the final stages too. The term “early stage design” is used to highlight that aspect which no other design system has.

Of course all design do start from early stages onward. That is a tautology. So sometimes architects do not get what is so special here. After all they do walk thru the usage of their favourite tool (even sketches on a paper) to go over the early stages. Those who like advanced CAD and BIM software often are seen to use them even in early stages without getting entangled in all the theories spoken here. They often cursorily do not get the importance in TAD.

Which is where the distinction between “loosely coupled” and “tightly coupled” needs to be explained. It is indeed important because as humans we tend to “adjust “ whatever tool we find to suit our loosely coupled situations. Without realising that the adjustment can be costly eventually.

Abraham Maslow says “When all you have is a hammer then all problems look like nails” referring to this capability to adjust that we have.

Now comes another important aspect of TAD. Even though it allows loosely-coupled way of designing it actually leaves inside the model which can be communicated accurately to other stakeholders. The language inside TAD has all the neutral alphabets of a language that the computer can understand. And so can the stakeholders.

This is a formal linguistic capability that TAD has. To understand this point, think of two types of human languages say Konkani and English.

Now Konkani is a spoken language with no predefined written formal alphabets. When someone speaks Konkani the best communication happens verbally.

People do write down Konkani using English alphabets. But then some may choose to use Devnagiri script or the Kannada script. That just shows that people want to communicate asynchronously too i.e the creator of knowledge in Konkani wants to convey it to a reader without the creator being present.

But if some Konkani was expressed in Devnagiri alphabets when the reader understands only English alphabets there will be no such asynchronous communication.

In short, Konkani is best expressed when people communicate synchronously and interpret the spoken words just in time.

When architects collaborate on a design; especially during early stages, it is more often than not a very introspective private exercise. If other stakeholders are interested in participating during the early stages they have to be synchronously together, interpreting the evolving design using the dialect they previously agree on.

Why should it matter? Why can’t design start privately in the mind of the main architect and let the collaboration happen in other more structured part of the design process?

Since sixties onward it has been proved that complexity can be intractable if the process is not handled sensitively from early stages. This is the “butterfly effect”. Lots of ills seen in the world that are due to architecture is attributable to this effect.

Here someone who is fond of some CAD/BIM may interject and say “But the ingredients of my CAD/BIM model also communicates” Sadly the structured model in such software do not adhere to the demands of a formal language as needed by the rigour of linguistics.

So to summarise: TAD is a design system that helps architects and other stakeholders collaborate together quite accurately from very early stages of design onward and leaves behind a body of work that can be plumbed for accurate information years later.

It is a system to allow use of models with formal linguistic alphabets.

At the same time it respects the loosely coupled nature of designing. In fact it can even simultaneously respect different priorities of different stakeholders. So I could start on a design of an apartment block with an eye on the carpet areas in the evolving design and my colleague can keep an eye on the evolving 3D forms.

The dependency on interpretation using drawings is no longer the main one when using TAD. The main architect is no longer standing on a pedestal speaking down to other stakeholders using a verbal interpreted dialect. It is critical that all stakeholders exchange information as clearly as possible not just for the eventual design but also during the process of design.

Today the field of architecture is possibly the last one where there is copious production of knowledge - with most of it kept in idiosyncratic personal silos. Too many ills in the world have resulted due to this.

In this note I have attempted to capture the critical differences why TAD has persisted thru the years. I would love to conduct workshops to advocate the use of TAD. At least the questions that TAD is asking are critical and are often unanswered. Those questions need healthy debates at the very least.

TAD is free and available from www.teamtad.com