"Teri Deewani"

The song "Teri Deewani" was a chart-buster. It was a definite heart-buster for me. First time I heard it along with viewing the music video, I was sold.

Umpteen loopings of the song on Winamp later, a peculiarity of the lyrics became apparent to me. The song is sung by a male singer but the lyrics are in a feminine voice. As if a female is meant to sing this song but is being sung by a male.

The song defnitely had a sufi influence. I vaguely remembered hearing more sufi songs which had distinct feminine voice but were sung in male voice. I explored this connection more.

Here is what I found. Quite interesting.

http://themysticalpath.wordpress.com/2009/03/22/centrality-of-the-divine-feminine-in-sufism/

http://www.utexas.edu/utpress/excerpts/exabbfem.html

http://www.h-net.org/reviews/showrev.php?id=9074

Feels great to just listen to a song and then discover this. :)

Add that to already fascinating concepts explored in Da Vinci Code, From Hell (Alan Moore, no less!) and Promethea (Alan Moore, again!), the conspiracy theory and mysticism loving part of me just went ga-ga!

Fight The Future

Some months ago, I watched a spate of time travel movies - "Timecrimes", "Primer", "12 Monkeys", "Donnie Darko". All had complex plot lines. None had the feel-good factor characteristic of such time travel movies as "Back to the Future" series.

A peculiar aspect of the screenplay of some these movies has grown upon me. In all these movies, the lead actors travel in time and interact with their own self. However, this interaction is at best of guarded caution while at its worst it can be downright malevolent. Their own self is their enemy.

An example of extreme worst case scenario comes from a movie belonging to a different genre. "The Prestige" has Hugh Jackman's character killing his own clones. I am still undecided which one of the clones would carry the feelings of the original Jackman and which one would be surprised to stare it his carbon / original copy getting ready to kill him. My thoughts start going on a tangent here - what does "self" mean, can memories be transplanted, can "self" exist outside body, can you harm your clone, etc.

I will explore that tangent some other time. Returning to the already mentioned theme of facing-off with own's self, a story idea has been taking shape in my mind. I will like to either write this story myself or experience it in any form of idea is someone has already taken a shot at it.

The idea goes like this. Tom, aged nearly 35, chances to experience time travel into past. He travels about 18 years back into time. Once there, he goes off to find his 17 year old self. Let me call Tom aged 35 as T35 and Tom aged 18 as T18. [Maybe this nomenclature is inspired by the upcoming "Terminator Salvation" movie and promise of the revival of Terminator series]

T18 is a brilliant kid. He is a geek, he understands time travel. He even dreams of experiencing it for himself in future. When T35 finds T18, the kid is not in for any massive shock. T18 is surprised but nothing more. T35 is thrilled to see his younger self. Together they hang around. T35 describes how things have shaped up in his life. The story of T18's future.

Here is the catch. The more T18 gets to know how the life turned out for T35, the more he gets uneasy. T35 appears a big time loser and all messed up to him. T35 has been shunned in his social circle, he is an outcast. T35 thinks that if no one else than at least T18 would be able to understand why things turned up that way. But he finds that T18 is not only aghast at T35's state, but is almost disowning his future self. T18 does not want to have anything to do with T35. He wants him to leave. He wants himself to leave.

That is the basic premise of the story idea. It will be interesting to witness the interaction with the same character's young and adult self. The young version -- all bubbly, positive, ambitious, raring to go. The adult version -- beaten blue and black, listless, defeated, out of spirit, out of luck. How will the young version deal with the apparent failure awaiting in his future and that failure personified in his future self? What will happen to T35 if the only person he had counted on to understand / empathize with him turned out to be the most disgusted after listening to his story?


One line summary of the above rant -- what if you went back in time and your younger self even refuses to recognizes you, feels disgusted at you? How did your life turn that way anyway?

Shaken, not just stirred

The terror attack which took Mumbai hostage for around 60 hrs has left me shaken; and not just stirred, as I usually had been on getting reports of bomb blasts in various Indian cities throughout 2008. Maybe some part of that can be attributed to my proximity to the incident which exacerbated my reaction. But, for the other parts, I am trying to find a reasons. And these reasons are perhaps only mine, and may well not be a representation of general populace.

I have become used to hearing about coordinated bomb blasts as a form of terrorism. (Well, that raises a question, what state of antipathy and resignation do I live in if I have become accustomed to such dastardly acts involving loss of human life?) Such events happen in a small span of time. They do leave behind a trail of blood and human tragedy, but they get over quickly. The particular city rebounds. On-lookers come on to see what is happening, maybe even lend a helping hand or two. Statesmen make flash visits to the site and then to the hospitals. Self-claimed strategic experts speak eloquently in media on what can be done to spruce up our intelligence agencies.

This attack was not like the above. It had a face. It was mobile. It was dynamic. It stretched to hours. It took hostages. It was both proactive as well as reactive. It was unpredictable. It targeted places of symbolic significance.

When I first heard of firings and news reports at around 2230 hrs on 26th Nov, somewhere I had the assurance that this is Mumbai and the matter will be swiftly dealt with. After all, how bad can firing incidents get? And this city has probably the best police force in entire nation. It was this last fact, which was soon going to be turned on its head.

The news channels flashed the image of ATS Chief Hemant Karkare donning his head gear and bulletproof vest to get going in the action. "ATS Chief has arrived, now it is just matter of few hours." Those were my thoughts. But after 2 hrs., the same channels reported that he was KIA. And not just him, in quick succession two other senior and star officers of Mumbai Police were reported KIA. It was then that I was hit hard, and a sense of terror engulfed me. They got 3 senior officials, and the situation is nowhere under control? Maybe it was the same time that Maharashtra Chief Minister and Indian Home Minister too realized that they are up against something they can't control through normal measures. Maybe it was then that someone who had to decide finally decided that NSG, along with whatever immediate support could be available (MarCos and Army Commandos), needed to be sent in. That span of 10 min. was when the gravity of this incident sunk into me.

To add to the terror then were the images of terrorists roaming in South Mumbai streets in a hijacked Police van! They drove close past a group of unsuspecting journalists and opened fire. The fact of loss of top police officers had unsettled me, and then it seemed as if the terrorists had taken control of police infrastructure itself.

It was a long night which followed. Some more damage was still left to be done. That came with the images of Taj Hotel heritage wing burning against the black, night sky. I have stayed there twice - once for AVB Scholarship interviews and then for some function related to my TAS summer internship. I have seen this as a symbol in umpteen number of movies and footages which revere Mumbai as "the city of dreams" and "the Maximum City". The shock of such an unimaginable thing actually happening was huge, and personal.

In the two days which followed, I kept hearing personal trauma stories. My friend's colleague's fiancé (marriage due next month) got shot. MD of my firm lives in NCPA building, right next to Oberoi, and he was sending mails that he can hear the sound of firing and grenade explosion and "it is really, really scary". Later, NSG commandos actually took position in NCPA to launch counter-strike. CEO of my roommate's firm walked in between bullet spray in Taj because he believed "his time was not yet up" and miraculously escaped when others around him got shot. A batch-mate was at Leopold when firings started and he saw two of his friends getting shot; one getting a fatal head shot, other getting a leg shot. At least two batch-mates reported remaining holed up in their office the entire night as their office are next to Oberoi and they hadn't left when the firings started. An IIMA professor was stuck inside Oberoi and he was rescued after 24 hrs. A friend's firm's chairman got killed in Oberoi. A friend stays close to Nariman House and was posting his own pics of the operations on Orkut.

These are personal stories. Not like hearing, xx no. of casualties in the current bomb-blast. Maybe, I as a member of particular social class normally doesn’t get affected by these incidents. However, this time, the target was this very social class. Somewhere in my social circle, somebody was affected.

My personal face-off with the terror occurred when a rumor of fresh firings spread at CST spread on 28th noon. News traveled fast. My house faces a main, busy street. People started running in opposite direction to that of VT. Shops started pulling down their shutters. Vehicles made U-turns in the middle of the road. The lane going towards CST became empty. Then, the vehicles started using both the lanes to rush in opposite direction to CST. It was chaos and panic. It was terror. It reminded me eerily of the Joker in Dark Knight. Look what these guys did to a city with some rounds of ammunition and meticulous planning. They got to the police, they got to a symbolic landmark and they got to business elite. When this happens, no one feels safe. If the top of the social pyramid can be taken hostage, the base of the pyramid has no clue about their safety.


This time, I was shaken, not just stirred.

What is the takeaway?

This may strike a chord with few of my friends who are voracious devourers of "information" off various media, prominent being the Web.

As a testimony to my eclectic nature, perhaps, I find almost any topic under the sun to arise my curiosity. It inevitably results in long hours spent scanning the sources of info, again primarily the web. The hyperlinks on web pages lead to a drilled down exploration of the subject matter. However, more often than not, the drilling is more sideways than vertical. That is to say, the links to some other allied topic. Few such lateral moves, and I may be reading something quite far removed from where I started. It gives a joy of exploration. On a sarcastic note, some may even call it a manifestation of Attention-deficit Hyperactivity Disorder (ADHD).

The problem I am increasingly facing is that of lack of retention of information I gained after spending valuable time in the exploration activity. As the subject matters get diverse, the attention gets spread too thin. The context switch from one topic to another gives thrill in the moment of exploration. But when asked later, maybe just after some hours, to give a brief on what was the takeaway on a particular topic, the brain just skips a beat (or a neuron synapse, to be more correct). It becomes tough to recall what was read. Sometimes, absolute zero looms on the mental projection screen.

This leads to some really frustrating moments. With limited time at disposal to pursue various activities in life (for professional development, personal enrichment or entertainment purposes), it appears that the time spent on the knowledge hunt went a complete waste. Once the moment of discovery of some new fact or information has passed, it is important that the piece of information to be parked somewhere in the memory. It should allow itself to be easily referenced, accessed and retrieved when the need arises.

What is the solution?

An easy one which comes to mind is to assess whether memory retentivity has reduced. It is a scary thought in itself. However, it may very well be possible if the brain is not getting enough "jog" in the daily routine. If one is only devouring info but not explicitly "thinking" about it, brain's memory creating abilities through techniques of "association" and "repetition" do not come into play. On a more general level, if one is not getting to solve couple of puzzles / riddles here and there, not doing quick numeric calculations once in a while, or just not getting exposed to quick witty humor, the brain's overall ability to fire cylinders when required may get reduced. Physical exercise plays as another important factor. A lazy body cannot host an active brain.

The difficult solutions to arrive at are related to changes in habit of such knowledge exploration, limiting exposure to a select set of subject matters or arriving at superior indexing mechanism. Let me take them up one at a time.

Knowledge exploration habit, like any other habit, may be quite difficult to change. It is the urge to explore the unknown which drives one to surf through the endless hyperlinks. The solution may lie not in curtailing the habit but actually taking it one step forward. One can try to write a short note, or just simply recall, on some of the topics he/she read during the course of the day. Forcing oneself to remember the subject matter may enhance the memory of it. Brain does not like gaps in info. It will quickly figure out that if only few disassociated scraps of subject matter are recallable, there must exist missing links. If the source material is ready at hand, one can then quickly glance through and fix the cracks. If the research done on the topic was exhaustive, writing a note summarizing the flow of ideas will be the best way to go about. This also provides a quick personal reference guide when one needs to access that information.

Limiting exposure to select of subjects is again about restraining one's habit. This appears to be a more difficult solution than the first one, depending on the extent of eclectic nature. Moreover, this problem is fluid rather than being static. The topics of preference change over time with new experiences, times and even with mood swings. How does one limit to a select set of subject matters is a difficult one to answer.

A superior indexing mechanism seems to be a clever idea. It does not demand curtailing habits of knowledge exploration and preserve the joy of the act. One scheme can be to use browser bookmarks extensively. You are outsourcing the brain's job to the software. Now, you have to just remember that you filed a particular piece of info for ready reference in a fixed location. If the browser provides for a superior bookmarking features (categories, folder structure, cloud view etc.), the source matter can be quickly accessed.

The clever solution (which does not appear so clever anymore now), will work if one is always connected to the Web whenever the need for such a info arises. It does not work in most practical situations. Especially when one is looking at using the info gathered in business situations and want the anecdotes / figures / facts to come out spontaneously and aid in business discussions. Now, this is what they call getting a bang for your buck. The buck here is the precious commodity "time" spent in consuming information. The bang is the timely and rightful use of it.

We tend to read X no. of blogs, Y no. of new sources, Z no. of dedicated magazines. We live in a connected world. Information explodes around us. Companies like Google realize that just making all this information easily searchable is a big money spinning business. Still, Google's help is only a reactive mechanism. You have to search for information when you require it. Any proactive mechanism ultimately has to reside in the brain itself. Proactive mechanism has to make use of the information already consumed and not start afresh in the hunt for it.

And that is the unsettling question which the post is asking. What is the takeaway? Or rather, how to ensure that you have a useful takeaway which can be taken out of brain when it is required? Those who have faced or are facing this predicament, do post your thoughts and discuss any solutions which come to your mind. That should be a good takeaway to have, once some useful ideas are here.

Hiatus A Deux

It has been a very long hiatus on this space for both me and Morpheus. The last post was published some 8 months ago. First quarter of 2008 saw me going through the rigmarole of campus placements. Once that long drawn process reached its happy conclusion, I headed to Himalayas (literally) to cool off. On my return, a beaming Neo walked the dais to get awarded with PGDM honor. Sweat and blood! What followed was a long due long break at home. It was after 5 years that I was getting to stay for an extended period of time in home town and with family. As May ended, I packed my bags to touchdown at Mumbai. The new home. Past 3 months have been a mix of trials & tribulations and survivals & jubilations. House hunt in Mumbai is a perspiring (humid hot) and jaw-dropping (astronomical real estate prices) experience. And the second go at corporate world is very much different from the previous one. That deserves a long post in itself. I am holding on that post till I have seen enough to make any justifiable comparisons.

All these and some more have kept me busy over the last 8 months. Too busy to return to the blog. Time to find my voice again. Time to make this blog alive again. But, where is Morpheus?

Commencement Speeches

Many of us would have watched and/or read Steve Job's "Stay Hungry, Stay Foolish" Stanford 2006 Commencement speech. The speech stirs up a new vigor and determination each time one reads it. I came across this site which lists some of the best Commencement speeches delivered at various US universities in recent times. They make a good read, especially when one is felling lazy and direction less.

While most of these speeches are generalist in nature, I found the recent talk delivered by Joel Spolsky at Yale Computer Science department quite engrossing because mixes very well the specificities of earning a Computer Science degree with the generalities of software profession. My own graduation day is just 3 months away. I wish that someone could deliver a similar speech pertinent to MBA context on that occasion. There is still a lot I don't understand about how my professional and personal life will shape up as a result of my undergoing this curriculum. Need some honest soul to cut to the chase.

ERI

When one of my friends returned after spending a 5-day session at a village in Gujarat for a course called "Exploring Roles and Idenity", it was time to reverse the gyan flow for some time. The course is said to reveal profound insights about one's own self. I was eager to know some generic outcomes of the group discussions which took there. This is one of the revelations which hit my friend hard. And sure, it hit me hard as well when he described the same.

In his own words, "The unique thing about this world is that you will always find someone who is better at an activity you thought you are pretty good at. And this is not restricted to mainstream activities like academic performance or career achievements. I am also talking about trivial things. Like, some trick of hand, a particular bicycle stunt, a balancing act, anything. Why, even the most absurd of Guiness records are broken by somebody at some point. You would have never thought somebody would care to master that obscure a feat. But people do."

Just to show an example on a funny note

Surprise!

I am lucky to have access to a grand library. IIMA’s library boasts of a collection of more than 150,000 books. For a bibliophile, a well-organized library can probably mean no less than a temple. I am not a 5-star bibliophile. Yet, when my peers throng the discotheques or find a new restaurant to relish fine tastes for their pallet on a Saturday evening, I prefer to be on my own roaming between the tall aisles of the book stacks in the library. I can sense ‘a smell of the books’. An overwhelming feeling fills me at such a time – there is so much to read and so little time. A chastising voice from inside reminds me of the unfinished books I have as backlog. The MBA programme introduced me to book genres which earlier had not come to my attention. These combined with all the earlier genres I have been following now pose the problem of choice. Instead of picking up new books to read, I just read the titles printed in bold letters across the side of the book. It has become a dare to take out just one book from such a huge collection and not let my attention get diverted to another book with an equally promising title. Gradually, I had stopped finding books. The surprise came when instead the book found me! On one of the excursions among the many I took into the library, I chanced upon a book which looked conspicuously apart from its neighbors. The ‘uniqueness’ might have been in the title as well as the cover art, I am not sure what. The subject matter just kept me hanging on as I read through the initial few pages. The reviews available on Internet confirmed that the book was a definitive work of the genre it was part of. I immediately got the book issued. A few happy reading hours after, I had added a new book genre to my kitty. It would be more difficult now to make my choices between the books, but I was not complaining. And as if to prove that this may be the only way for me to pick up new books, similar incident happened again after a month. Another random book picked and fallen in love with. How I wish that same luck would play in meeting people! Next time you do not find me answering my phone, you know which alleys I am wandering through. Some book out there is waiting for me to find it!

Hinduism, World War II and AC Roma

Surprises come in quanta. And these quanta came bunched together this time while I was traveling to my hometown for the Diwali vacations. As I gathered to seat myself on the carefully apriori chosen window seat, a wrinkled skin old lady asked me whether I would exchange the seat wither so that she could take the window seat. An elder citizen is hard to be denied such a request given the Good Samaritan I am. Soon she was calling her folks back describing how a ‘gentleman’ had just allowed her the window seat and now she would be able to enjoy the view outside.

The surprises were yet to come. The grand old lady was wearing a cotton saree and had prayer beads adorning her like a necklace. However, her fair skin and accented English intrigued me; that is quite uncommon for an Indian granny. I asked her, “Are you Indian?” And she replied, “Yes, but I was Italian”.

Well, that explained a fair bit. Soon afterwards the small talk ensued about who I am, where I am heading to, why I am heading there. I answered and then asked the same questions to her. The quanta kept firing from this point onwards. She had come to India in 1965 to pursue her PhD in Hindu religious studies from the Banaras Hindu University. And she neither knew English nor Hindi when she arrived here.

Her PhD guide advised her to choose a language to learn for communication. It would have been a tough call, but she chose English. Over the years, she not only completed her PhD but also found her love in an Indian student. She married here and then got settled in Varanasi. She had kids and they had their own kids and she is now actually a granny of many kids. That’s one happy ending Bollywood would be proud of.

She told me that she no longer likes it back in Italy when she visits her relatives. 40 years of India, Hinduism, Varanasi and family have changed the way she looks at life. Her peers in Italy are unable to reconcile her views. I asked her, “Were you a Catholic?” She answered, “Yes, I was. But, now I more Hindu than anything else.” Her PhD had been on the Brahmanic aspect of Hinduism. Varanasi being a prime seat of the Tantric aspect as well, I inquired whether her research touched on it as well. She hadn’t looked into those details but said that some of her friends had worked in that area. However, she said, any mainstream literature is hard to come by as it does not adequate academic support.

A quick calculation ran through my mind about her age and I could not stop myself from asking, “Did you witness the War?”. And yes she had. She was 7 years old when World War II got over. She had seen the friendly German occupation of Italy, the entry of Poles towards the end of the war, the departure of Germans and the entry of British. For the first time I was meeting a person who could give firsthand account of the War which has never stopped fascinating me. This was also the first time that I was getting to hear out somebody from the Axis side. She was quite affectionate about the Germans. They, she said, treated them very well and helped them in garrisoning food for the coming conflict with the Allies. The Germans would help them in digging bunkers and showing them safe hide-outs in case of a bomb raid. In fact, she hated the Poles for entering their country. The Germans left their town when the Polish army started assembling on the borders. The Poles would then use Italian women and children as cover to pursue the retreating German soldiers. The granny was bitter that the Poles used them as covers to kill the friendly Germans. And she hated the British more, because they used the Poles as a cover to follow the Germans. She gave graphic account of bombing raids and how she had twice narrowly escaped the Allied rocket-launcher bombs. That was some conversation.

The conversation drifted towards sports. The granny had more aces her sleeves. Soon she was describing her fandom for Francisco Totti. She regularly follows Italian league and went on to discuss the dynamics between various clubs and why Totti should keep playing for AS Roma instead of selling himself to Juventus. I was feeling seriously handicapped to deal with the topic at hand and all the more surprised since all of it was coming so naturally to the granny. She went to proclaim her love for hockey and how beautiful a game ice-hockey is. Cricket certainly did not figure in the list of her admired sports.

I suppose she would have thrown more surprises my way but for the flight descent into Varanasi airport. It was the most interesting journey I had in a long time. World War II to AC Roma, way to go!

Don't corrode you 2 Rupee coin !

The New 2 Rupees coin. 2007.

If you corrode your coin at the wrong
places, see what happens.









this blogpost is dedicated to the stupidity of those people who seem to think that the new 2 Rupee coin (not this one, the earlier one) is a covert effort by the Government of India to spread Christianity in India. True, that 2 Re. coin is liable to be confused with a 1 Re. coin (especially by blind people), but that's all the problem I have with it. If that Cross is a Christian Cross, then I'm afraid so is using + and x in mathematics. Read and laugh about this bizarre story here and here.

The "auto" in the automobile is here

November 3rd 2007, will witness the third round of DARPA Urban Challenge, which is a prize competition for driverless cars, sponsored by the Defense Advances Research Projects Agency (DARPA), the central research organization of the United States Department of Defense. The upcoming event and status of the teams participating in it had appeared in an article in November 1st 2007 issue of The Economist. Few relevant excerpt from the same:

"....(DARPA), has scaled back the traditional process of handing out large research grants and getting nothing useful in return. Instead, it has been running a series of grand prix for such vehicles. The prix in the latest, due to take place on November 3rd, is $3.5m—of which $2m will go to the vehicle best able to negotiate its way..."

"....The favourites are Stanford and Carnegie Mellon University (whose car came second in 2005). As in a more conventional motor race, the logos of their sponsors—companies such as Google, Intel and Red Bull—cover almost every centimetre of their vehicles, reflecting millions of dollars in investments...."

"....The established mixture of competitiveness and amateur fair play will surely continue (teams routinely patch up each other's wrecks after a crash). And that seems to produce for DARPA what many millions spent on more run-of-the-mill research projects has failed to generate."

The detour from traditional closely guarded military-industrial-complex research to an open, competitive is quite a stepping stone and its effectiveness demonstrated by the swift progress made by technologies showcased by the teams. Watch out for results of this event to be held tomorrow at the DARPA site.

Here is video showcasing the maneuvers of Junior, the "autonomous vehicle technology" mobile built by the event favorites, the team from Stanford University.

The Man With No Name

On a recent lazy weekend, I watched the movie trilogy featuring the iconic character of “Man with No Name” played by Clint Eastwood in the movies “A Fistful of Dollars”, “For a Few Dollars More” and “The Good, the Bad, and the Ugly”. The movies are a treat to watch and regarded as the classics of the Western genre. However, it is Clint Eastwood’s character which is quite intriguing. He is in fact one of the more popular manifestations of a particular class of male on-screen characters – they work mostly alone, are a master of their art (either fighting skills or detective acumen) and generally do not get paired with any female character.

It fascinates me to think that how these men are able to immediately make their mark upon the scene on which they arrive. Their demeanor is one of raw confidence just short of haughtiness. They are men of few words, accurate actions and unexpressed sentiments. Their morality is in a ‘grey zone’ – they don’t hesitate in double crossing other characters who themselves are not necessarily evil. Probably, they are closer to reality than the other heroic figures on screen which hold high moral ground and fight for honor, country, love etc. While the latter leave the audience with a surge of inspiration, the former bring a wry smile to the face. One wouldn’t want to mess up with these loners and would prefer to be on neutral territory with them. Their friendship does not exist as such, except when they betray a shade or two of emotion and do the ‘right’ thing by saving/helping some minor characters in distress.

I find the IQ - independence quotient - of these “Man with No Name” characters to be quite extraordinary. It is perhaps a quality to be sought for when the environment around one is of constant conflict of interests, when friendly terms with people around get evaluated and re-calibrated quite often, and when trust on a person is an outcome of Game Theory playing itself out in the given circumstances. This character is at peace with his shades of grey, unlike the superhero story themes as in Batman. The character, though conniving and manipulative, is also not the anti-hero which we are familiar with. He is most likely to be the survivor of the lot in thrillers with a heist as central theme of the plot.

However, the movies comfortably skip some of the issues which concern the sustenance and survival of the ‘Lone Gunman’ characters. These characters have no place which they can call home as they are almost always on move. They generally don’t have a ‘occupation’ which would make them work in teams, face customers or report weekly to a boss. They either are ‘self employed’ (in Clint Eastwood’s case, as a bounty killer) or work for someone but have entire decision making power (the super-agents like Ethan Hunt and Bourne who are an agency unto themselves). We are never told where they hold-up when they fall ill, who bakes their daily bread and how they survive old age. So, while one may get pulled to live a life on the edge like that, it is imperative to find answers to these somewhat mundane but nevertheless vital questions.

Also, such men are not born. They are made. There have to exist triggers to make a person to turn his back on the society. Though they are not sociopaths, yet they too don’t exhibit generally accepted social behavior. The movies generally skip the part of the character transformation of these individuals. Rarely, like the Star Wars trilogy, the attempt is made to understand why the transformation occurred.

I may not have, yet, concrete explanation of these ambiguities, but I can make a fair guess at one thing – these lone warriors would most probably not be maintaining public blogs. It must be against their very nature to put across their views in an elaborate manner. So, those of you (me included) who want to holster up and dig your stirrups into your stallions from tomorrow morning, please put up a bye-bye post on your blog.

Space Tourism

I had been recently looking at the area of Space Tourism for developing an idea for a Business-plan competition. Logging some of my findings below.

There are no recent (2007) research articles which analyze the economics of space tourism. Surprisingly, most of the relevant articles I found date back to 2000. While space tourism has leaped from a sci-fi dream to commercial relality in past 3-4 years, there does not appear to be any academic research going into this area. Please point me any latest articles you may have come across.

Some articles I could find:

History of Space Tourism

Commercial Implications of Market Research on Space Tourism (a 1994 paper)

Near-term prospects for Space Tourism (a 2000 paper)

Public Choice Economics and Space Policy: Realising Space Tourism (a 2000 paper)

The Space Tourism Industry in 2030 (a 2000 paper)

The Mythical Man-Month

The Mythical Man Month

The Mythical Man-Month was written by Frederick D. Brooks in 1975 and deals with various aspects of problems related to software engineering. The book is considered to be a masterpiece and features on various suggested reading lists including that of Joel Spolsky. After undergoing an elective course on "Managing Software Projects and Enterprises" during my 4th term of PGP curriculum at IIM Ahmedabad, I decided to read the book and hopefully summarize the essence of its text. The following is a chapter-wise summary of the book. The work was first published in 1975, and republished as an anniversary edition in 1995 with the essay "No Silver Bullet" and commentary by the author.

1. THE TAR PIT

An interesting concept of how debugged programs can be turned into useful commercial entities. A 'program', here, means a debugged piece of code which performs some specific task. A 'programming product' is a program that can be run, repaired and extended by anybody. It is useable in many operating environments and for many set of data. A 'programming system' can be thought to be analogous to a development platform. It comprises of debugged components and established interfaces which can be used to build larger programs.

1. Program	2. Programming System
3. Programming Product	4. Programming Systems Product

Brook's says that it is 3 times for difficult to transition across a horizontal or vertical boundary. Hence, moving from A to B or C requires 3 times the effort of building A. So, moving from A to D would require 9 times the effort!

The chapter emphasizes the fact the programming is a craft and the pleasure associated with it are due to several reasons like cognitive freedom, thrill of creation etc. The same reasons result in the woes of the craft as well - jumbled thoughts, no physical system to test complications, burden of taking the entire responsibility on our self for failed ideas, etc.

2. THE MYTHICAL MAN MONTH

Schedule estimates go awry because they are made on an optimistic premise that everything will go right. The strong belief in our own competency and the fact that a programming idea is purely internal, unaffected by physical limitations of equipment or material resources available, clouds the reality.

The Brook's law is postulated as - "Adding manpower to late software project makes it later". The author argues that using 'man-month' as a unit of measurement of effort is a dangerous practice. Reasons behind this are:

1. Increasing number of people increases communication overheads and training time.

2. Tasks are sequential and adding people doesn't make them parallel.

The thumb rule for scheduling a software task is given as:

1/3 planning

1/6 coding

1/4 component test and early systems test

1/4 complete system test

3. THE SURGICAL TEAM

The problem addressed in this chapter is that competencies among peers is not equal. Sometimes the order of difference can be as large as 10 times! Ideally, one would like 'a small, sharp team'. A new organization structure based on a surgical team paradigm is proposed:

1. The Surgeon - The chief programmer. He personally defines the functional and performance specifications and designs the program.

2. The Copilot - Alter ego of the surgeon, he knows all the code intimately. He researches alternative design strategies and points out flaws in the Surgeon's approach. However, the Surgeon is not bound to accept his recommendations.

3. The Administrator - He handles money, people, resources and interfaces with rest of the administration of the organization. The Surgeon is the boss, The Administrator is the manager.

4. The Editor - Though the Surgeon generated documentation for clarifying his own thought process, the Editor criticizes it and improves it by adding references and maintaining versions.

5. Two Secretaries - One each for the Administrator and the Editor to assist in paper work.

6. The Program Clerk - He maintains all the technical records, maintains libraries and keeps the code repository in shape.

7. The Toolsmith - Responsible for providing, maintaining and upgrading programmer tools like file editing, text editing, IDEs, makefiles, debuggers, build environment etc.

8. The Tester - He writes the test cases, carries out all phases of testing and acts as a friendly adversary to the Surgeon.

9. The Language Lawyer - If the system under development is a programming language or a platform, this guy will showcase to the world the neat tricks and tips of using the system. He is the spokesperson, tech-support and marketer of the system.

The surgical team works because there is no division of work and a superior-subordinate relationship is maintained. However, it can't work for large projects. Moreover, the issue of suppression of creativity of members other than the Surgeon comes into play.

4. Aristocracy, Democracy and System Design

A system design should reflect a conceptual integrity rather than a patch up of good but anomalous features. Also, there should be a fine balance between functionality and conceptual simplicity of a programming system. Excess of either can result in loss of purpose. Conceptual integrity demands that design should be a product of a single mind or a very small number of similar thinking minds. However, large projects need many people for implementation. This paradox can be resolved in two ways - by separating architecture from implementation and by following the proposed Surgical Team organization. The issue of hindered creativity of developers can be resolved by recognizing that even the implementation within the bounds of a defined architecture requires lot of creativity and decision making.

5. The Second System Effect

Some important tips are given for the architecture to not get overenthusiastic while designing the system.

1. Remember that the programmers have the creative freedom on their implementation. So don't start dictating on that front.

2. Always be prepared to suggest one way of implementing things. However, accept the developer's way whenever he differs.

3. Deal quietly and privately in such suggestions.

4. Be ready to forego any credit for improvements.

When an architect develops a system for the first time, he will be extra cautious and careful. However, some or the other problem will always creep in as the exercise proceeds. The third and later systems he designs will be in conformation to his earlier experiences and general patterns he has observed during the development cycle. However, the second system is the most dangerous as the architect will always have a tendency to over-design the second system. The architect should avoid functional ornamentation and stretching of functions far beyond their required purpose.

6. Passing The Word

Dissemination of information regarding design and implementation details is critical to the success of a project. Written specifications should capture all the intents of the user; even if this process has to through several iterations to achieve concurrency of minds. The style must be precise, full and accurately details. However, the specification document should not venture into the implementation aspects of the system.

Generally, when there is a confrontation between a manual and the actual implementation, the manual loses. However, this can't be afforded when a programming language or a platform is being built.

7. Why Did The Tower of Babel Fail?

Tower of Babel is described as the first human engineering project to fail. The first one, Noah's Ark, was a resounding success. The failure came because the groups involved developed dissonance because of different languages they spoke. A software project is doomed to meet the same fate if the different stakeholders are not on the same communication plane. Teams require to communicate among themselves in as many ways as possible - informally, through meetings and by maintaining workbooks.

The maintenance of workbook has been explained in detail. For large projects, workbooks tend to grow to prohibitive sizes. In such circumstances, maintaining a change summary on top of major revisions (with the help of already available well-advanced text editors) should be practiced.

As the organization size grows, the number of communication interfaces invariable explodes. With this respect, achieving division of labor and specialization of function achieves paramount importance. To illustrate the fact, a relevant excerpt for the book "The Man Who Sold The Man" has been presented.

8. Calling The Shot

The chapter describes the inherent fallacy in extrapolating short-run project productivity and phase-wise time distribution data (i.e. fraction of total time used for design, coding, testing etc.) to estimate the effort for large projects. It is shown that the effort increases exponentially rather than linearly. The exponent estimated from sample data is 1.5. Data from various studies are given to highlight this aspect.

9. Ten Pounds in a Five-Pound Stack

Program size control and memory footprint reduction are the main them of this chapter. The information presented is from the view of Systems Programming and emphasis has been given to prevention of the already limited system memory with large programs. No specific technique is dealt in detail. Mention has been given to algorithm complexity, space vs. time trade-offs, space vs. functionality trade-offs, overlay technique to reuse memory etc.

10. The Documentary Hypothesis

The hypothesis, verbatim copied from the book, is as follows:

"Amid a wash of paper, a small number of documents become the critical pivots around which every project's management revolves. There are the manager's chief personal tools."

The critical documents are - Objectives, Specifications, Schedule, Budget, Organization chart, Space Allocations and Cost Estimates. An illustration of the idea is made by describing the documents required for managing a University Department.

11. Plan The System for Change

The ideas presented in this chapter are quite radical. The journey from prototype to final customer deliverable product cannot be one giant leap. There is bound to be an intermediate state of system development when unforeseen problems accumulated while scaling from prototype to deliverable product make further development tedious and patchy. The system has to be redesigned from scratch keeping in mind the learning from such an exercise. Moreover, customer requests and expectations will also change as the system develops and they play with it. In such a scenario, it will be foolhardy to be headstrong about "doing it right the first time". A throw-away system should be part of the schedule planning itself and not come as an afterthought or compulsion.

Also, the organization structure should be such as to allow the architect and implementers the flexibility to have one throw-away system. The architect will tend to be defensive about his design and will not commit to put it in writing as later it is bound to backfire. The managers and technical team should be interchangeable as much as their talents allow to achieve such a flexibility.

The bug-fixing process is described as 'two steps forward, one step backward'. All repairs tend to destabilize the overall architecture of the system. This happens because bug fixing is generally done by junior programmers who don't have completely overview of the system and it is unknown that removal of a local defect causes what effects in some other part of the system. To quote from C. S. Lewis:

"That is the key to history. Terrific energy is expended - civilizations are built up - excellent institutions devised; but each time something goes wrong. Some fatal flaw always brings the selfish and cruel people to the top, and then it all slides back into misery and ruin. In fact, the machine conks. It seems to start up all right and runs a few yards, and then it breaks down."

12. Sharp Tools

Tools are quintessential to the system development process. However, there exist personal preferences of each member of team for a particular tool amongst various available options. Also, people tend to guard their tools as they are a reflection of hard-earned personal skills. This approach is destructive for a programming team. Hence, as discussed in the Surgical Team, the toolmaker is responsible for acquiring, distributing, maintaining and upgrading the tools. He also makes specific tools for the chief programmer as the need be. The various tools which a manager must plan for are:

1. Computer facility - Target machines (for which the system is being developed) and vehicle machines (on which the system is developed)

2. Operating system

3. Programming language

4. Debugging aids

Note: The technical details in this chapter are quite dated. C is not even mentioned as a system programming language. RAD tools are too far beyond the horizon.

13. The Whole and The Parts

Testing philosophy and details are the focus of this chapter. Careful function definition and testing the specification itself is the first safeguard against potential bugs. A top-down approach of specification development is proposed. One should sketch a rough task definition and a rough solution method that achieves the principal result. Then one examines the definition more closely to see how the result differs from what is wanted, and one takes the large steps of solution and them down into smaller steps. Each refinement in the definition of the task becomes a refinement in the algorithm for solution, and each may be accompanied by refinement in data representation.

The details of debugging techniques are dated. Structured programming and discouragement of GOTO usage is heralded as the way ahead. Debugging techniques like On-machine debugging, Memory dumps, Snapshots and Interactive debugging are discussed.

It is suggested that for system testing, one should use only debugged components. One should not use bolt-it-together-and-try approach as this mixes system bugs with component bugs. Whenever a new or improved component is added or replaced in the system, the entire system testing should be redone. Plenty of test support architecture should be built. Generating automated test code and test data may require as much as 50% of the effort to write actual code. But this infrastructure is necessary for speedy testing and delivering a robust product. Also, changes made during bug fixing should be well controlled. All changes should get documented and should be clearly identifiable till they get tested and do not become integral part of the system.

14. Hatching a Catastrophe

"How does a project get late? …. One day at a time." Thus begins the chapter on managing schedule slippage. It is argued that big catastrophes or failures in design receive immediate attention and hence get sorted as quickly as possible. However, small slippages like sick leaves, executive meeting, unplanned customer visit, system outage etc. go unnoticed and people take optimistic attitude that they can be covered.

It is suggested to have concrete, definable "milestones" to keep track of the project progress. Milestones should be unambiguous. Fuzzy milestones will result to overlooking of slippages by both the line managers as well as the project manager.

An interesting result is shown from two studies conducted on estimating behavior of government contractors on large scale projects:

1. Estimates of the length of an activity, made and revised carefully every two weeks before the activity starts, do not significantly change as the start time draws near, no matter how wrong they ultimately turn out to be.

2. During the activity, overestimates of duration come steadily down as the activity proceeds.

3. Underestimates do not change significantly during the activity until about three weeks before the scheduled completion.

There is an inherent conflict of interest between line-managers and project manager on dealing with slippages. A line-manager would not want to reveal the small problems to project manager and try to deal it himself. Project Manager, though, needs to know the true picture in order to plan for slippages. The situation is aggravated when the Project Managers convert a 'status review' meeting into a 'problem solution' exercise. The Project Manager should accept the status reports without panic or preemption and let the line-manager deal the situation.

PERT techniques go a long way in providing the exact picture of effects of schedule slippages in the components. Because PERT is an elaborate technique, at least a critical path analysis should be done. A 'Plans and Controls' team is suggested to manage the tasks of gathering information and carrying out the PERT analysis. The team should be diplomatic and should devise inventive ways of unobtrusive but effective control methods.

15. The Other Face

A program has two faces - one which is seen by the machine and other which is seen by human user. The other face should be intelligible to a user of the program. Note that that 'the user' here may be different from the programmer who wrote the program code. Thus, documenting a program is very essential. However, documentation is more preached than practiced. A company should not establish elaborate documentation policies because experience shows that earlier generation of programmers were not able to follow the practice as desired and neither will current generation of programmers.

There may be 3 types of program users - a casual user of program (load and execute), one who depends upon the program for functionality (use library or component) and one who must adapt the program (feature enhancement or future versions).

A simple 3-4 page prose documentation suffices for the needs of a casual user. The following information should be captured - purpose of the program, system requirements, valid domain of input and range of output, any standard algorithms used, input-output format, command line syntax and abort sequence, expected running time for a problem of specified size on a specified machine configuration and means to perform error checking of results.

A component user requires a suite of test cases to validate the library after it has been integrated in his own code. The test cases needed are:

o Functionality test for commonly encountered data

o Edge cases on the input data domain

o Barely illegitimate cases from the other side of input domain boundary to test for proper exception raising and handling.

For future code modifiers, the source code itself should serve as a documentation. Variable names, initialization labels, code block indentations, function names etc. should all help in telling the story in their own right. Paragraph form of comments should be inserted to explain the logic flow. One should not get into complication of drawing elaborate multi-page flowcharts. A flowchart has utility only if it can be compresses into a single page to show the top level program organization. In theory, flow chart should drive the code. But in practice, flow chart is generated after code is written to comply to company policies. Why create rules and harp on them which have traditionally never been followed?

16. No Silver Bullet - Essence and Accident in Software Engineering

This chapter was added into the 1987 edition of the book. No Silver Bullet - essence and accidents of software engineering is a well-known paper on software engineering written by Brooks in 1986. Brooks argues that there will be no more technologies or practices that will serve as 'silver bullets' (legends say tat only silver bullets can be used to kill werewolves) and create a twofold improvement in programmer productivity over two years. The entire text can be found here.

17. "No Silver Bullet" Refired

Several articles were written by Brook's contemporaries as a rebuttal as well as support of Brook's arguments in his No Silver Bullet paper. This chapter is meant as an answer and explanation to these responses. Again, the brief summary of the arguments can be found here.

18. Propositions of The Mythical Man-Month: true or false?

This chapter presents a point-wise summary of ideas presented in the 15 chapters of the initial edition of the book. It may be a useful section to preserve as a handy reference-guide.

19. The Mythical Man-Month after 20 Years

Brooks goes on to expound on relevance of his theories and ideas in context of 1995, 20 years after the first edition was published. While some of the core principles have attained increasingly strong position, some implementation ideas have either been proven wrong or become obsolete with microcomputer revolution and advances in programming tools and languages.

The central argument of the conceptual integrity and the separation of architect from implementers appears more convincing than ever. Though enterprise level solutions pose the challenge of efficiently implementing the functional separation concept, yet divide-and-conquer and recursion techniques like maintain architects for major function areas under a principal architect can achieve the benefits proposed.

Shrinkwrapped software products give rise to 'Featuritis', the besetting temptation for the architect to overload the product with marginal utility features. Also, the larger and more amorphous the user set, the more necessary it is to define it explicitly if one is to achieve conceptual integrity. A system architect should find out (or guess, if data is not available) on the relative frequency of different attributes of the user set. Such exercise is immensely helpful in defining the scope and complexity of the product.

The idea of a planning for a throw-away system (Chapter 11) seems to contradict the caution given against second system effect (Chapter 5). However, Brooks explains that the confusion is linguistic. The second system in Chapter 11 is the second try at building what should be the first system fielded.

The success of WIMP interface (Windows, Icons, Menus and Pointing Devices - a terminology used for GUI when it was first proposed by Doug Engelbart in his historic 1968 demo and later developed at Xerox Palo Alto Research Center. The story of Steve Jobs "coaxing" Xerox management to showcase the technology to him, its porting to 'Lisa', triumph on Macintosh and 'influence' on Windows is an interesting sidetrack to follow) is cited as a triumphant example of conceptual integrity and successful metaphor conforming to the mental models of desktop workspace arrangement. Substantial critique is made of various aspects of WIMP in about 4 pages.

Attention is next drawn to the Waterfall Model of Software Engineering. This sequential method of developing software is acknowledged as implicitly assumed in suggestions such as 'build one to throw away' and proportioning time between design, development and testing. Brooks admits that that the suggestions derived as such suffer from the basic fallacy of waterfall model in that it assumes a project goes through the process once, that the architecture is excellent and easy to use, the implementation design is sound and the realization is fixable as testing proceeds.

An incremental-build model is suggested as better for progressive refinement. An end-to-end exoskeleton is first built according to the design decisions but has blank function bodies. The functions are incrementally fleshed out and system testing is performed at each significant increment. This ensures that there is a debugged, tested system at every stage. Microsoft's daily-build process, incremental-build and rapid prototyping are explained in this context. Further, the importance of Object Oriented programming and its properties like information hiding, data abstraction and inheritance are shown to give tremendous advantage in following an incremental-build as well as code reuse approach.

Empirical, independent studies are then referred for showing the validity of Mythical Man-Month and Brooke's Law. The Brooke's Law is modified on the basis of data to show that its possible to finish a slipping project on time by adding manpower but only if this is down before the middle of the project timeline. Any later additions will result in project delay. There will be a drop in efficiency immediately after manpower addition. However, given enough time (i.e. for new developers to become familiar with program and knowledge dissemination having taken place) the efficiency can come back on track.

'Peopleware' is given more credence now. The real assets of the project are its people. A heavy price has to be paid for moving projects between different teams or loss of knowledge due to attrition. It is also suggested that power of decision making should be transferred deep down the organization hierarchy as much as can be warranted. Example of Microsoft product development teams is given to highlight the productivity gained by such a management philosophy.

The last 10 pages of the book are devoted the phenomenon of explosive growth of microcomputer and the allied industry of shrinkwrapped software. The technological improvements in hardware have made overcome various accidental (term used by Brook to refer to the implementation aspect of the software development) restrictions mentioned in earlier chapters. The development platform choices have coalesced into few operating systems. One can now buy software off-the-shelf rather than incurring expenses for in-house or outsourced development. Brooks makes the observation that organizations have learnt to modify their business processes to fit to these available software products rather than putting efforts into building a software highly customized to their original processes. In the areas where this does not change the very basic nature of organization's business model, there is cost saving to be made by this paradigm shift. Also, accidental complexities are proposed to be only 1/10th of the overall complexity in building a software product. Hardware and development tools improvements only attack accidental complexities and the order of magnitude in efficiency gains obtained thus can at maximum eliminate 1/10th of overall complexity. The rest 9/10th complexity is due to essence, I.e. the design conceptualization of software product. Earlier nothing significant was available to attack this complexity. But emergence of shrinkwrapped software and expected emergence of components market (off-the-shelf C++ classes) has given rise to build-on-package phenomenon which truly attacks the essence complexity.

Lastly, it is hoped that software engineering will truly attain the properties of an engineering discipline when distinctive processes giving exact results would have been identified to build software.

Steve Jobs and Bill Gates, together!

Jobs and Gates appeared together on stage to interview for D5 at All Things Digital. It was a fitting culmination of my two week long sojourn into the history of personal computing. I had watched Pirates of the Silicon Valley, read Fire in the Valley, saw Apple 1984 superbowl ad, unearthed clippings from Triumph of the Nerds, enjoyed some really creative ads of Mac vs. PC (here and here), heard Job's Stanford 'Stay Hungry, Stay Foolish' commencement speech, got acquainted with antics of Jobs, and had even seen the entire Apple WWDC 1997 when Jobs announced Apple entering into partnership with Microsoft and Gates was towering above him from the projector screen.

Here are the YouTube links to the interview video (10 parts of 8 min. each):

http://www.youtube.com/watch?v=6G3Vcy7u8Gs

http://www.youtube.com/watch?v=RlnapkgH6bQ

http://www.youtube.com/watch?v=tEd6WzDczzE

http://www.youtube.com/watch?v=oZTQeqpdDYQ

http://www.youtube.com/watch?v=vwYxjgyPHNM

http://www.youtube.com/watch?v=4k8ZUxMSb3M

http://www.youtube.com/watch?v=tN3Y5_Yjkd8

http://www.youtube.com/watch?v=tWf0n2S-L3s

http://www.youtube.com/watch?v=TMxR-XDTeG4

http://www.youtube.com/watch?v=wqTDBArvHQE

http://www.youtube.com/watch?v=wqTDBArvHQE

Hibernation

The last post from my side was made some 2 months ago. Mr. McNamara's few advices still need to be chronicled. Random discussions, which have been major source for the underlying themes of my posts, have dried out. The group with which I regularly rallied on such matters has ceased to exist for all practical purposes. These and such other reasons have put the blog into hibernation.

Paradoxical as it may seem, the number of ideas sharing my mind-space have, however, multiplied. It has been becoming increasingly difficult to prevent the mind from hopping from one thread of thoughts to another. The time-splice allocated to activities have become ridiculously small. Here, sum-of-parts cannot much a contiguous total.

Hesitation has also set in to pour out seemingly non-business thoughts in public domain. Authoring on some niche topic would have been probably easier and the blog could have mostly cruised in auto-pilot mode.

I met Morpheus on 11th June. We were meeting after nearly 2.5 years. Morpheus has been in his own thick of things. Generally our troughs and crests of blogging alternate. A steady flow of posts had been thus maintained. This time, however, we both have hit "sleep mode" on our individual blogger-pods at the same time. Come on Morpheus, show Neo the path, as you are supposed to. Free your mind (and time)! Lets see some posts here, friend.

Fog of War (Part II)

(continued from Part I)

4. Maximize efficiency

A significant wastage of efforts ensues when decisions are on live-wire and desperate moves seem to be the last resort out. Inefficient planning will not only delay the achievement of the objective but also put heavy drain on resources thereby significantly altering the strategic advantages. It s imperative to look at the efficacy with which success is being achieved. A brute force method is only good so long as micro-management is not required. Otherwise, somebody has to hard-sell an efficient solution, which defies established thumb rules, to his/her superiors.

During WW-II, the Allied forces were initially using China as the airbase for its Japan bombing operations. The B-29 bombers were being flown in from Kansas, USA to Arunachal Pradesh, India. They would then be loaded with fuel and fly across the Himalayas to China airbases. The fuel would be off-loaded for creating reserves for mainland Japan bombing operations. The Chinese air-field were constructed by manual labor. The whole operation was insanely inefficient. It was only when the action arena was transferred to Pacific (and Mariana) theater that a swift progress was made by US against Japan. The decision of transferring entire war-machinery from one theater to another would have required great conviction as well as convincing.

5. Proportionality should be guideline in war

Every war has its own magnitude of what is acceptable as "collateral damage". However, both parties should adhere to the limits of this number. A mindless action by one party (maybe another manifestation of "brute force") could blow apart this unwritten rule of war. Killing of civilians, women and children has always been deplored when the winner tramples over the vanquished. But as human race builds better and better weapons of mass destruction, the idea of proportionality of destruction has been buried by the desire to win (and experiment) in the minds of military leaderships.

US dropped two atomics bombs on Japan after they had destroyed some 67 Japanese cities to the tune of 50% to 90%. On a single night of fire bombing (using "incendiary bombs") on Tokyo, more than hundred thousand people were annihilated. Tokyo was then primarily a wooden city and fire bombs wreaked havoc. Dropping two atomic bombs after causing so much destruction was an act completely out of proportion to whatever had been the scale of US-Japan war , unarguably the most brutal war in the history of mankind.

6. Get the data

The most obvious deductions don't require geniuses to figure them out. But, even the not obvious ones need not wait for geniuses to unearth them. Relevant data can be the crucial differentiating factor between circuitous, futile analysis of problems as opposed to hitting the bull's eye. Data can put into perspective the subjective judgments and give a replicable framework to arrive at insightful conclusions. In the wake of missing data, a successful decision will appear a lucky guess in retrospect. However, a word of caution - data without proper tools and methodology to analyze is no good than junk.

Fog of War

Robert McNamara is former US Secretary of Defense. He has served under both Kennedy as well as Johnson administration. In essence, this makes him a key player in two very important events in the Cold War era - the Cuban Missile Crisis and the Vietnam War. BBC produced a documentary "Fog of War" (2004) in which Robert McNamara narrates "11 lessons" he has learnt through his experiences by living the Cold War 24 X 7 for 7 years (1961 - 68) of his life. McNamara is attributed by some to be a "war-monger" responsible for causing heavy losses by not reducing US involvement in Vietnam. However, his these insights should be taken from viewpoint of a skilled manager rather than a war hero. Here is my own interpretation of these "11 lessons" coupled with the facts narrated in the documentary.

1. Empathize with your enemy

One must understand the mental state of the enemy. Every person, especially if he is leading others, wants to walk away from a conflict feeling vindicated. If the situation is clearly understood, one may actually afford to let the enemy "feel" victorious (or at least vindicated) to have more fruitful outcomes in one's own favor. In the Cuban Missile Crisis, Kennedy let Khrushchev tell Russians that the Commies were successful in "preventing" an American invasion on Cuba; while at the other hand, Americans were able to get the nuclear warheads dismantled from Cuba without having to shed a single drop of blood. Khrushchev got something to give back to his countrymen out of the conflict he had chosen to escalate and Americans were happy to let the Commies believe that they had bullied USA while achieving the real purpose of diffusing the impending nuclear war.

2. Rationality will not save us

The belief in Game Theory that all actors are "rational" does not work in when human beings are under pressure. One cannot trust "enemy's rationality" to plan out his/her moves. The following snippet of conversation proves this by revealing how scaringly close the world had reached the brink of a nuclear war because of "unexpected irrational" behavior.

When Fidel Castro was asked by McNamara almost 20 years after the Cuban Missile Crisis:

1. Did he know the nuclear warheads were already fitted into the Russian missiles (i.e. missiles were "launch ready")?
2. If you knew that, would you have recommended to Khrushchev to use them in face of an US attack?
3. If he had used them, what would have happened to Cuba?

Castro replied:

1. I knew they were there.
2. I would not *have* recommended it to Khrushchev, I *did* recommend that to Khrushchev.
3. We would have been totally destroyed.

3. There's something beyond one's self

One has to observe and adhere to the values which are extrinsic to the conflict situation. The war may tend to make one weak, immoral or deceitful; but how much one succumbs is a matter of strength of personal will-power as well as the gravity of situation. Also, beyond the high adrenaline action, one should be (in an ideal situation) able to love his family and cherish the happy moments spent with them.

(to be contd..)

Better than salsa

Stupid as it may sound, the forces that be have made me formally answer why I am fit to be part of a computer gaming community. An excerpt from same:

Q - What are your expectations from the community?
A - To allow to prove that a left arrow tap (“dodge” move) can be as scintillating as a salsa step.

Q - Any prior experience in gaming?
A - Extract from my 'last working day' mail to gamer’s club at workplace:

“I bow to the gallery and take farewell from the arena. It was an honor to fight the warriors. As they said in Troy, 'I walked with the giants'. So long, till our IP addresses ping the same server for another round of gore."

This Summers

I was alive and kicking for the past 2 months. Summer Internship time. It was great to be back in actual work atmosphere, to tackle the ambiguities and organization hierarchies, to hear middle management tell "this is how business is done", to know that its a bad world out there and there are no pretenses to portray the contrary.

My project was making a business case for a project to be taken up by my organization. It involved aspects right from demand estimation to evaluating business models to making breakeven analysis to chalk-out implementation details. Here are some of my personal learnings from the Summer Internship. They may be particular to the nature of project and may not be relevant in entirety for all MBA Summer Internships.

1. Identify the organization hierarchy
2. Know the operational touch point in each deptt.
3. Understand the business

• Nature of business
• Market
• Competitors
• Pricing - Landed cost at each point in supply chain, nature and reasons for margins in each case
• Customer segments
• Customer expectations
• Ground situation where the product is used (perceived quality and utility)
• Recent changes in the market - arrival of new competitors, changes in market of primary product if the product under study is a derived product
• Expected trends in near future and in long term
• Macroeconomic, social and political factors which have implications on business regulations, consumer behavior, supply chain relationships and logistics.

4. Company's history - past lows, success/failures of high risk projects/ turnarounds
5. Changes in organization structure, new management changes in recent past, effects of this on policies and business
6. Stakeholders in the project

• Whom is the report intended for?
• Is it a "recommendation" or a "validation"? A "recommendation" is used by middle management to get buy-in from senior management. A "validation" is commissioned by senior management to make middle management work and prove that the senior's vision or gut feeling is quantitatively correct
• Are there opposing views in the organization on the final decision? If yes, why? Which side are you on? How do you defend your recommendation in weak/grey areas of analysis.
• Which party is stronger? You are working under which party?

7. Gathering information

• Generate contacts - they will lead to top or middle management of other organizations (logistics provider, distributors, marketing agency etc.)
• Get the details of field and/or operational person - the most important source of info which will shape the analysis
• Open both the formal and informal channels of communication. Informal info comes only from people in field, who are closer to the customer than to the power dynamics in management
• Keep making sense of the info and how it is helping in the final evaluation of the business idea. Don't pursue a line of thought if it seems academically sound but doesn't have data available or does not make business sense.
• Data may not be readily available. Try to find secondary data if primary data is not available. Assume percentages where there is no data and ask the relevant people in field or middle management to approve the assumptions or correct it

8. Analysis

• Make a tree structure of different decision paths
• Make a 2-3 level analysis by generating options, evaluating and recommending for the various implementation details of the business
• Make a PPT which can navigate through these different paths - use hyperlinks, which can easily take one back at the parent node at any point
• Use sensitivity analysis where assuming some numbers as input data to show that if the actual is off by 5% or 10% either ways, how much will it affect the final result
• Use graphs judiciously so that the visual representation of data directly makes that impact ("moment of enlightenment") which you felt when the data started making sense to you. Each chart-style has its own nature of impact. Pie chart - best represents share/contribution. Scatter plot - best represents trade-off analysis
• Put charts on PPT and use hyperlinks to invoke the Excel files which have calculation. People assume that the numbers have been worked and don’t want to see Excel sheets. They want to see them only when the final result or trend reported by you does not fit the perception they had been carrying about that matter. Then you will need to convince them with the data and calculations
• Insert extra worksheet in each Excel file which contains data sources - Name of the person, Actual data file. This gives credibility to input data
• Show incremental recommendations after analyzing each sub-area of decision to show that you are slowly building up the solution to the bigger problem

9. Validation

• Try to validate and "stress-test" your recommendation
• If possible, try to run some simulation by inputting live/actual data to show what will be the performance of your proposed solution. This analysis may throw surprises and suggest area which need to be explored apart from the problem in question. Maybe the root-cause may come out to be somewhere else.

10. Winding up

• Even after the appraisal, get a feel of what is the opinion of various stakeholders on the both the analysis and results. People will open up earlier withheld information and/or personal opinions in order to either support or invalidate your recommendation. This will let you know what to watch out for when doing a similar analysis.
• Write thank-you mails to all who have helped with their insights and data collection. Don't divulge actual recommendations to parties outside the organization.

11. Organization skills

• Understand your official level in the organization
• Try to maintain the hierarchy structure if its strictly followed in the organization
• Socialize with the peer or immediate junior level employees of the organization. The informal info on both the boss as well as the project is much helpful
• Get to know the HR systems, various job profiles, satisfaction levels, possible career growth etc. so that it helps to make a decision in case you are offered a PPO.