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.

Handling complexity: What India really contributes

It has been quite some years since I spoke about this, but I think my experience with Konkan Railway needs to have a wider exposure.  This article is partly based on something I wrote in a private discussion group among my IIT friends on Facebook.

The objective of this article is to share my optimism about India and the way we do things here. I have a lot of optimism about Indians and the way we work. Of course there were a lot of scoundrels and calamities on the way but I tend to always see the full portion of the half-empty glass.

Let me stick to one example. I worked quite closely with Konkan Railway, so in one sense I could be biased. But on the other hand, I could be revealing some insights. I think Konkan Railway as a project has been discussed threadbare to the point of almost disbelief.

So I wont go there.

Let me tell you about my experience when designing the headquarters. Initially, I too was hesitant when I got the job -- designing their headquarters; that too in just 45 days from inception to handing over was a challenge to anyone and I was just too young (27 years). I was amazed that it got done and the thought struck me how details sometimes are so different from helicopter-views.

I had to contend with 15 railwaymen -- many of them picked out of retirement and brought back into service. All of them cranky in their way, very demanding; and tough to please. I thought they would create a hurdle in the project's management. They didn't. In retrospect, and when I later on married my experience in IT and my readings in management (Mythical Man Month, for example) these old fogies will run circles and ellipses around any project management guru.

They are the unspoken heroes and their way of working was amazing. I saw, for example, the Konkan Railway system of managing files. They called it a "single-file" system. Everything pertaining to a project went into one file and that was circulated around. It was bulky, clumsy but it worked charmingly well. Everyone who had to take a decision got a complete holistic view of what was going on. Most of the time, they did not write separate reports: Many officials would just turn over a paper, and write their comments on the back of the page; so one got to read the file in two directions: One in the forward direction, and one by looking at the reverse side of the pages for the decisions and recommendations

(A method that I have seen another friend of mine, Dr. Nobhojit Roy, use for his diaries. I think talking about Dr. Roy's ways of working will take a lot of effort and space. Let me not digress here)

They had several other ways of working. For example; Nobody lifted their intercom phone. It was always on speaker-phone. Anybody in the cabin would be able to overhear what was going on. I quickly realized that they wanted everyone to hear.

There are many other points that I noticed in the way they worked:

The interior design did not ask for a clock. Instead they had "countdown" counter that read out the number of days left for the project to be completed.  When the staff trooped in for work each day, the counter will boldly indicate the number and prime them.

Each cabin had a mini traffic signal outside the door: Red indicated that the person inside was really busy and should not be disturbed. Amber to indicate that please knock and then enter. And Green was to just breeze in unasked if you wanted to meet the person inside.

Many years later, I was teaching MIS at a management institute, and I realized how naive many of the Western approaches were. Some Japanese consultants were visiting the interior when it was being constructed; and they refused to believe that the entire thing would be over in the total stipulated time of 45 days. It was 15,000 square-feet with all kinds of issues, spaces, requirements ... all in the middle of a working office. But it really did get done.

17 years later, Konkan Railway bought another floor in the same building and I did that one too -- equally speedily. In the meantime, Konkan Railway had stopped being a "corporation" (Initially it was on a BOT scheme, but later it was handed over the railways ... and yes, there are stereotypical imagery of the "railways") So indeed, the new Konkan Railway was boring, bureaucratic and all that . But the new interior also was done quite fast.

And when I went to do the new interior, I was happy to notice that the 17 year old office interior I had designed was more or less being used using the same arrangement I had made. They even had replicated my modules in some other portions of that floor space.

On a side note, this project was the one of the first in my practice that utilized my own design software; TAD. I never made any drawings for this initially. I just plonked my computer with my software among the officers of Konkan Railway and quickly fleshed out the layout of the interior directly in the software. It was running on DOS those days. Those of you who are interested, can take a look at TAD here: http://ww3.teamtad.com  The second Konkan Railway interior, and indeed, every project done by SFA was developed around TAD.

So what is the point of this article? Indians solve really tough problems reasonably well. Konkan Railway is a project that has been admired and acknowledged all over the world. It did not come up in a vacuum  There were lots of complex detailing and handling of complex activities, such as this interior. They were also done admirably well. I think the biggest contribution that Indians make is the ability to work on the "holistic" instead of just being analytical (divide-and-conquer) when solving a problem. We offer the perfect foil to reductionism. I guess that many top organizations have realized that and they are quickly moving in to India to set up their R+D cells. Google, IBM, Microsoft, Adobe ... they all have their research cells here to tap into the Indian way of handling problems.

I had the opportunity to visit Copenhagen and I was struck when someone pointed out to a group of 6 out in the street and remarked that there is a "crowd" out there.  They had a metro, a railway with two different kinds of trains if I mistake not, amazing road work, cycle-lanes and what not ... All that, and a crowd of 6.

I then remembered my work for the control-office building of Konkan Railway (which later on did not come up ... another story) As part of that exercise I got intimate with the working of the control offices of both western and central railway. I was given some numbers ; and those numbers flashed on my mind: Churchgate station alone handles the entire population of Denmark in two days. Huh! Hmmm... and they were talking of a crowd of 6.

This is not to deride and make a strawman of the Danish way of handling problems. Indians know how to join seemingly opposite points of view where the Western world use derivatives of the age old Greek method of the law of the excluded middle.  Lotfi Zadeh explains that aspect of Buddhism quite admirably, when he explains how he got onto fuzzy logic. My life tells me that not many Western approaches know how to work with the "synthesis". Not that they simply cannot solve complex problems at all. I've had other experiences with the Danish, and they have their own ways of working which also works admirably well.  I should write another article on my experience with using, beta-testing and writing documentation for Visual Prolog, quite an efficient and off-beat computer language developed in Denmark.

I just believe that the world has not yet recognized the way we Indians work, and I truly take pride in having being involved in some part of the new Indian workforce and methods of working. My company, SFA (Sabu Francis & Associates for short) grew up in this milieu. Hopefully, this way of working will be spread far and wide by those who had worked for SFA and have now spread out.

Ride my donkey

This article is on how to understand critical thinking, writing and rationality; and feigned rationality.  I was anyway planning to write one for my students, and I recently got an opportunity. Sometimes arguments are brought to one's doorstep, to be discussed threadbare. This blog article is also my response to some very recent happenings on the Internet. I guess, as a medium, Internet is still growing up and many of us are still grappling on how to discuss a topic formally and yes, rationally.

The way the events unfolded:
a) An organization I was involved with decided to chip in with some help for the marriage of some women in the villages
b) The event was publicised on Facebook
c) One person decides to object to it on the event page; stating that initially she liked the idea but on closer examination she found the approach incorrect. That by itself was quite fine. However the tone was a bit aggressive with some hidden innuendos and quite bad net-etiquette (e.g. usage of a lot of question marks, which suggests being perplexed, hidden agenda, etc) One of the founders found the tone objectionable but worked on the meaning anyway
d) A discussion ensued which resulted in some more clarification, and eventually we removed the vagueness and clarified the description of the event


I would have thought the matter would have ended with a sober response; such as: "Okay, I have now made my point. Mission accomplished. Let them at least raise at least some money, after all the organization is known for its good work"

But guess what? The matter did not end there. It resulted in a kind of a "Whoopee! Got the chaps! They changed the description  Oh, and did we laugh about it, etc". And all that on her blog.

She has remarked quite clearly that she was making a rational point, and she claims we were not really entertaining that. So let me now enter the subject of her discussion and not about the event or the organization and discuss the logical fallacies she herself is making regarding the subject of helping women, based on the exact words that she used. This is not an allegation on the person. I am merely using this opportunity to gain some insights into logical fallacies and incorrect argumentation.

I have heard this kind of pseudo-intellectual talk from my IIT days and it is high time I need to explain how sometimes arguments are made quite irrationally. I think some do this quite innocently, possibly because they really do not know formal argumentation.

The basic message that she seems to promote is that she knows what it is to improve the lot of tribal women and our organisation simply does not know what it is all about.

Note: This is not to prove one point or the other. This is just to understand how do we get into a topic and what could possibly the way to argue the point

So let me start with the initial reaction that this lady had given and I will discuss that in detail. The rest of the conversation is possibly not very important because it mostly continued in a similar vein on the part of most of the authors in that thread.

This is what she had started the conversation thread with:

After reading about your cause of funding 25 marriages for "our sisters in villages", I feel you'll are sending out the wrong message on so many levels. Women are better off without men who call off a wedding for monetary reasons. Your cause only reinforces dowry, a patriarchal society reducing these women to "inferior" beings. What about educating, empowering these women and making them self sufficient instead of just paying for their weddings????

1. After reading about your cause of funding 25 marriages for "our sisters in villages", I feel you'll are sending out the wrong message on so many levels. 

This sentence is fine. Almost. Talking about feelings is always correct. Nobody can question feelings.  The part which is a bit odd is "message on so many levels" is a dangling statement. What levels? Is that explained later? If so, then that is fine. If not explained clearly, it ends up being very suggestive that there could be some hidden agenda. It ends up as an innuendo.

2. Women are better off without men who call off a wedding for monetary reasons.

This is an over-generalization and also a sweeping statement. It implies that women are better off without men of a particular kind of ethical behaviour. Are things so clean and clear-cut?  People are complex creatures who are both good and bad; and there are women who can still derive benefit from being married to such men. This sentence also hints that the monetary reasons for calling off weddings are only due to a conspiracy against women. Poor people call off a wedding because they simply cannot afford it. Can't that be a reason? What about two poor souls deeply in love, who cannot marry because neither have enough money?

3. Your cause only reinforces dowry, a patriarchal society reducing these women to "inferior" beings. 

This is called a slippery-slope argument. She starts with a point which she assumes to be correct (She states quite emphatically that the cause "only reinforces dowry" note;  In any argument we should not start with a conclusion but arrive at it. In this case, if her hassle was with dowry we need to clearly establish that our cause is indeed to reinforce dowry) She then keeps sliding away into "reinforcing dowry", "patriarchal society" "and reducing women into inferior beings" ... if one were to hazard a guess, if that slide along that slope were to continue maybe one could easily slip in many other ills in the society too -- hmmm drunken husbands? corruption?   and it can go on and on. A casual reader could even get convinced. 

Here is the formal explanation of the fallacy of the slippery slope: http://rationalwiki.org/wiki/Slippery_slope 

Slippery slope arguments when told extremely fast, which does not allow much time for the listener to react can often convince the listener. It is a popular technique among glib salespeople. Hmmm.. You want a devious website? here is one describing the use of slippery-slopes for sales http://www.solo-e.com/articles/internet-marketing/website-design/13-steps-slippery-slope-online-sales-letter-307.shtml 

4. What about educating, empowering these women and making them self sufficient instead of just paying for their weddings????

What about all that? This one is called a non-sequitur fallacy. She has stated some premise and her conclusions do not seem to be connected to the premise. For example; if I were to add this to her sentence thus: What about giving wholesome, nutritious food to the ladies? it would go quite well with what she is stating. And the list can then continue to more "good" alternatives which on closer examination may not have much to do with the premise.

Non-sequiturs are used dramatically in comedy shows and I've seen some hilarious non-sequiturs used on Radion 91.1 FM after the end of their fillers each day on "Babbar Shair" http://www.planetradiocity.com/radiocity/city.php?id=19&title=Mumbai

In some arguments, non-sequiturs can be easily spotted and are indeed, quite humorous.  But in some emotionally worded (or sometimes cleverly worded) arguments, it may be difficult to spot non-sequiturs.  Read here more about the fallacy of the non-sequitur here http://rationalwiki.org/wiki/Non_sequitur  Pay extra attention to the subtle ones

I have just enumerated a few fallacies that I found just in the first paragraph of the initial statement itself made by this lady. I have possibly missed several other logical fallacies in that thread. I am sure there are many in her blog too but I am not going into all of them here. I do have one comment on the specific article she wrote about this on her blog: She is making a Straw-man argument there, which is best explained here: http://rationalwiki.org/wiki/Straw_man

Now my students reading this may wonder, so what is the answer to this question of helping tribal women. My answer is: The answer is not very simple and surely cannot be gleaned over an Internet discussion. My recommended strategy to extract an answer is to examine the subject using the Socratic method; which I will explain later in another article. Briefly, the Socratic method starts with a position of innocence and then questions each premise carefully for internal contradictions. It takes time but in the end, one often gets to know what could be the correct answer (often the answer is contextual -- works for one situation but may need to be re-examined for another context)

It is sad that the lady assumed some kind of controversy here. I tried telling her later in a private message that gender issues are extremely complex and taking binary (i.e. on-off positions) are too simplistic. Sadly, she did not respond to my query. It turns out that she has even blocked me on Facebook, for some strange reason.

Whether the organization is really doing something deep is not the issue here; at least I know for the fact that there is a lot of genuine effort that would indeed help some monetarily.  It may be just a small little thing but I know for a fact there is no conspiracy here.

Yes, indeed, the money collected could be used for the wrong reasons and one need to guard against that. If points on how to protect and use the money correctly were discussed, the discussion would have been more productive. We could have passed on constructive suggestions to the charity who is behind this effort.

It is amusing to see that the author fervently believes that she is really making a "Rational" argument here. In fact her blog proudly declares this "When rationality, music and causes collide " I wish she would read up on logical fallacies. Else, she is welcome to attend my classes.

Some of my friends wonder why I bother so much about fine points on argumentation. Firstly, I must confess, like anyone here; I too am bothered about my own argumentation capability. As an architect, and later as an IT person, I have heard just too much arbitrary arguments which wastes too much time and in the end, only the points of the more "impressive" personality seems to be registered. I get vexxed when students make such points because later on they are to conquer the world and I wonder how they would do so. A healthy amount of skepticism and a capability to look deep inside all the corners of an argument can indeed reap a lot of benefits. And when I hear claims of feigned rationality, well, I can seriously get on the verge of being impolite.

You may be wondering why this article is called "Ride my Donkey" I picked that from something that I heard Kamal Hassan say in an interview which was aired once-again after his recent controversy. He had to change the name of a movie simply because some politician thought of deriving mileage from that controversy and you can hear Kamal say about it here:

(See the part after 9minutes 30 seconds) He says that he was used as a donkey for someone else's political agenda.

So it is not just the big guns like Kamal Hassan who are used as a donkey for various agendas. Some smaller souls who are trying in their own way to get some help where it is needed also get taken for a ride. I am not really sure whether a donkey was ridden in our case. I hope not. After reading her blog, I did get the feeling that the person was consciously or unconsciously reinforcing her own image as a "women" saviour; for reasons best known to her.

And let me end this on a positive note to the lady if she decides to read this. It is with the same positive humor she ended her blog: Madam, please do take my blog as a educational lesson. It could, just might, help you sometime. All the best wishes in your endeavour to help women. I am sure you will now make really good arguments

P.S: I am deliberating not mentioning this lady's name or give a link to her blog here. I hereby declare that is NOT made as any justification or defence of the organization I am involved with; referred to in this topic. This is my personal stance as a teacher, and it is meant purely for educational purpose only and it is not to slur anyone