TAD Docs

Everyone has heard of JIT (Just-in-time) For e.g. Dell supposedly uses JIT manufacturing to keep their inventory costs low and quality high. They have processes that ensures that detects what kind of computers are being ordered by their customers; and all their assembly kicks into place just-in-time Reputedly; they do not have much inventory because of this.

Just in time modelling is a concept that allows TAD to be a lean, mean machine. Many have wondered why is it that TAD files can be so drastically small. That is because, the author realized that it is pointless to give slots into the data structure to store potential properties of the elements of the design.

Why so?

Because when you are a designer, it is you who dictates what properties those elements should have and not any software programmer. So Sabu invented a neat way of combining data with code that can further enrich the data. Quite often that additional power is not used by the designer and hence the TAD file size remains small. But if the designer so needs; he/she can decide exactly what additional properties need to be given to the elements in the design.

This is very suitable for a design process that starts from very early stages of design and proceeds to later stages – at every stage the designer would surely get surprises which would change the way the architecture elements

Anecdotally speaking: here is the wife of a client insisting that the flooring in the design has to be of marble just because she happened to visit a friend who had that marble floor … there can be many such examples. Architectural design is full of such demands imposed during the design process.

One can even say that it is because TAD allows such last minute, just-in-time changes, it is extremely realistic to the workings of a design firm – especially in developing countries.

What are slots in the data structure?
Ah, I forgot to explain. In conventional BIM and other design software; the software company assumes certain properties that the design may need and inserts slots into the data – which can be filled by the designer as he/she develops the design in their software. In software parlance; one would say that the structure to receive standard properties are hard-coded

You may think that what would happen if those slots are not filled? Well, all such software gracefully handles the situation where the designer did not fill up those properties. But that does not mean those empty slots would go away. In software and maths, even zero is a value – so all such unfilled slots (aka properties) would still occupy considerable space – not just that; the software needs to load in all those empty slots at startup when loading the design – one of the main reasons why not just is their data very large but it also takes a long time to load (There are other reasons too – I am possibly over-simplifying the case)

You may wonder why is that other software companies did NOT adopt such an approach? Well the simple answer is to go and ask them

But I suspect it is because of the tendency of some people to think that the world is a nicely deterministic place – where all the designs out there have explainable properties. It kind of looks apparent, doesn't it? After all if we were to talk about, say flooring, what could be the properties that would represent that element?

One may think: density, hardness, color, texture… and so on. It looks as if they can all be conveniently listed and therefore pre-prepared slots can be given to the designer in the software; for the designer to fill in as needed. TAD is a lot more humble:

TAD says “I really do not know what all properties that you may need to enrich a particular element of the design. So I have slots only for the bare minimum. However, if you want to add more properties, be my guest and add it thru ARDELA; the internal scripting engine inside TAD”

Here is a curious mythological story from India: In the story of Mahabaratha is an incident where one important person (Draupadi) laughed when she saw her cousin slip and fall on a smoothly polished floor – and that person got so embarrassed and annoyed – one version of the fable states that this insult went deep.

Now imagine having a property of the floor called insult-value … This may sound strange to someone – but it takes all kinds of interpretations to make up this world. A software developer cannot dictate what should be represented and what not. Especially in architecture. Especially in architecture built in developing countries – where there are old traditions, craftsmanship and value systems and some of those can't be codified by a software developer. Only the designer may elect to do so just in time when the importance of that property is impressed upon the designer.

From version 6.8 of TAD, it even allows exporting to Haxe . With Haxe you can take your model AND all the properties in it; into another computer language (you have choices there!) – which makes the use of TAD really wide open! This approach again respects the fact that it is the designer who would want to add more properties; and not really the software developer.

To put it simply; TAD avoids bringing complexities into the hands of the designer. The person at the helm of TAD usually is an important person in the office (often the main designer) He or she would have other things to attend to. TAD gives expression to those who want to flesh out salient points to be considered when designing. The juniors in the office can then take up the rest later without the main person around.

Hence TAD is very realistic and it can surely help the main designers add a lot of richness in designing – a richness that opens up just in time keeping pace with the way the design is evolved!

To put it simply; TAD is a lot more practical that seen in the way design properties are handled in other software.

You can even say the concept of just-in-time modelling first started in TAD! Well you should. TAD had this approach from 1989!