God is in the data

(This is an excerpt from my forthcoming book "Where is the elephant?" -- on complexity in architecture. I am hoping to entice architects to take a deeper look at my way of designing architecture using TAD. It's free. Download and register from www.teamtad.com)

We are in the new Renaissance once again. Where botanists can sit comfortably with mathematicians. And musicians with nuclear physicists. Or geologists with poets.

And make sense.

So I hope my architect colleagues won't mind me distorting Mies van der Rohe's famous quote "God is in the details"

The details are in the data.

The stuff that we all gloss over so easily when we flip through a book. Or get so impressed, that the book becomes a stopping point rather than a starting one.

Data is the stuff we teach our students. Yet often we do not teach them how to really make sense out of it -- when all we do is quote them verbatim or worse; make our own personal interpretations which often turn out to be like making proclamations after peering into the entrails of a tea-cup.

can we really make the complexity out there tractable?

We have some lovely books in architecture alright. There are lots to be learned from them. Let me not undervalue the act of interpreting someone else's take on architecture. It's just that we need to be quite wise on how to do those interpretations.

I remember reading Charles Jencks book "The Language of Post Modern Architecture". The first line started "Modernism died on .... " and he goes on to explain what happened at Pruitt-Igoe.

There were three outcomes from that famous event at St. Louis. One was to do with a specialized yet important branch of architecture -- Environment-Behaviour. The second was to do with post-modernism and other investigations into various "isms" (which is where Charles Jencks book fits in -- though I object to the usage of the word "language" in there)

And the third one was to search answers for a seemingly simple question: can we really make the complexity out there tractable?

For things have gone far too complex and out of our hands. We need assistance. No amount of fine book readings are sufficient. We need to hand over some stuff to computers just so that we have enough time to mull over things where only subjective interpretations can provide the answer -- and the irony is that I need to write a book just to convince that.

Now this begs a question: What part of the data do we hand over to a computer? And what is that part that we human architects have to pore over, interpret and respond? This boundary is yet another area where the lessons of the mythological story of Narasimha is at work.

For far too long, the reductionist way of looking at data in clean, clear slots had ruled the way intellectuals tackled complex issues.

Even when we teach students, we slot our field into clear subjects: Climatology, Building Materials, History .... and some of these students are indeed given the boon by the Gods of their respective institutions:

You have prayed hard, my son/daughter; says the God at the end of the exam. So I won't fail you in Climatology. I won't fail you in Building Materials. You won't die in History and so on.

Then the fresh architect starts practicing only to fail when Narasimha rips him/her apart at the boundary between these subjects. No wonder the students nowadays say they have "passed out" rather than graduated.

So to decide on the boundary between what needs to be given to a computer and what is to be retained by the architect for interpretations is a really tough decision indeed.

Data is actually the starting point of a "food chain" of wisdom. The chain starts at data alright. Then it moves into information when we add meta-data into it (meta-data is "information about information") From that point we get knowledge once the meta-data becomes context sensitive. Computers cant get all of knowledge, just the explicit parts.

Tacit knowledge is just about getting into the reach of Artificial Intelligence (which is why there is so much hubris around AI nowadays). Wisdom is still out of reach of any automation and is the pinnacle in this food-chain.

Now let me step through another boundary and look at the problem from the perspective of someone from computer science.

The way a computer works; it cannot handle shades of gray too well. Someone may object to this and actually take me literally -- and point out that we have millions of colors that can be shown on a monitor. Well, even that is "pixelated" and slotted in a reductionist manner. But I was not talking of only that -- computer cannot handle ambiguity too well, wherever it arises.

This fait accompli unfortunately resulted in a short-cut when assembling large amount of "structured data" -- where the computer had to store categories of information. A whole area (which many consider quite holy) of RDBMS (Relational Database Management Systems) came into existence. Here too, they assumed that the categories are distinctly defined. Again, I attribute this to the deep underlying influence of the philosophy of reductionism.

In the early days of the use of computer, RDBMS achieved very impressive results. Taking census of a country, for example. Imagine the puny processors inside the computers of the fifties and sixties and the tiny amount of RAM they had. Even when the micro-computer was invented in 1981/82, the maximum RAM one could get was 1 MB (that is 1024 kilo-bytes) of which 640Kb could be used at any given time.

So the computer gurus figured out clever ways to optimize those limited resources. But in the process, they threw the baby out with the bathe-water: Firstly, data is never so distinct. And now, the categories themselves are never distinct

And third more insidious issue with data is that one can never get full data in the real world at one shot.

Here's an example: Take a leaf from a cheque book. How I wish I get one with all the values filled in a proper signature at the end and a valid date too. But no, a cheque starts life as a blank, useless cheque. It belongs to a bank alright but because the rest of the information is not present in the cheque it stands useless for its eventual purpose.

But at the same time, we cannot suddenly conjure up a cheque just as when we get all the ingredients together. So obviously, the cheque starts life as partial information and then over time it becomes complete.

That is the kind of shades of gray which are difficult to handle by computers. In this case of how data starts out rather skinny at first and then gets fully fleshed out later.

Of course this was just a simple example and some RDBMS aficionado would protest that this can easily be handled inside a "table" in a database: Just leave the fields empty till the time it gets filled up

But data has the capability to move from one category to another one wily-nily too. And in fact there are many situations where they don't fit into any category too well at all.

This was the context which you see in conventional CAD programs (and subsequently BIM programs that arose from the code-base of CAD programs) These software use what is known as a "segmented" database -- basically a database of databases. With the data all slotted nicely and firmly into place.

When we use Autocad or Sketchup or Revit, our hands are actually dictated by the tight-coupling that these software demands of us from our data.

For example; Revit will never allow you to talk of a window opening by itself. That concept does not exist -- in Revit, you need to have a wall or some built matter into which an opening goes.

But life is not so easy. Often an architect can stand at a site and mull over the possibility of having a window just there -- like a film director viewing a scenery and holding up a frame between his fingers to capture the right view.

The data is incomplete and yet, we need something to capture that situation. Somewhere this kind of incomplete data has to be jotted down, right? Revit can't do this. TAD does this. (pardon my small advertisement here)

Fortunately, the internal resources available to computers grew rapidly -- it's called the Moore's law.

That opened up many new ways of looking at data, including the pet grouse I have with RDBMS -- of having tight couplings.

Today lot of modern software is written using the strategy of "loose couplings" rather than tight ones.

HTML is a data system used inside browsers and it has enough loose coupling that the browser can tolerate a lot of differences and yet be able to render a page for you to read on the web. There are no real rigid slots in there. Most of the slots are quite flexible in their boundaries.

The AI people gave one more insight: They said, why not convert some of the data into code that gets executed just as when you need it? So instead of storing some piece of data rigidly you squirrel away some code there. And that code fetches the data for you just as you need it.

Both these strategies can open up other headaches too if not thought through deeply. For example; code can get caught endlessly chasing its own tail and never give you the data at all (the computer would "hang") And loosely coupled data can end up with unexpected contradictions which can yield unrealistic results

Nevertheless, these are known pitfalls and lots of work has happened in this area. Prolog, for example, is a wonderful computer language that is quite receptive to incomplete data. It is also easy to think up data in Prolog that turns into code to produce more data.

What all this means, is that a complex fluid subject such as architecture now has a game chance of being represented a lot more realistically rather than rigidly. The loving details that Mies van de Rohe wanted us to get into are all now possible.

The question that I asked at the beginning: What data should we give over to the computer? And what should we keep with ourselves? Well the answer is that with a loosely coupled system, you can postpone it and handle it each case at a time. That is much better than being dictated to every time

There are three nice breakthroughs in TAD. One is that it uses the aforementioned "loosely-coupled" way of handling data. The second is that it allows for internal reflection and extension. That means, internally, in some situations; the data actually turns into code and gets executed inside the software to produce more data.

And the third characteristic in TAD is that the data is quite minimalist. You talk only of the stuff you really want to talk about -- files in TAD are typically in kilobytes, even when handling very large projects. Even a very large project like the extension building I designed for Churchgate railway station is just 167 Kilobytes. It is there as one of the samples. It did not get built -- another back-story which I will narrate some other time.

If you didn't understand that fully, never mind. Just start using TAD and you would get a hang of it soon enough. Just open up one of the samples and click on the 3D view -- internally, the ARDELA (ARchitectural DEsign LAnguage, based on Prolog) engine kicks into life and actually converts some of the data into code, generates more data from that freshly made internal code and then renders the view for you

What all this now means is that there is now a game chance of writing books (or whatever it would be called when it is partly in book form and partly online) in our subject of architecture where all the theories can take advantage of a sophisticated representation system for the complex subject of architecture. So instead of just having empty quotable-quotes, we can now talk of a more deeper and meaningful knowledge emerging in our subject