The Compass and the Clock

While going through my ever growing list of unread mails, I chanced upon a “feel good” forwarded email. Usually I skim through such emails with a cynical disdain. However, in one of them, a sentence that had the words “satisfaction”, “success”, “compass”, “clock” in some order caught my attention.

My career so far has been a 15 year long journey. There have been highs and lows but overall it has been satisfying. When I look back, I realize that I have sometimes followed the compass and sometimes followed the clock.

Following the clock is about racing against time and trying to climb the “ladder” as fast as one could. Comparing oneself with peers and feeling the pressure to perform, more in the way of accomplishing things as fast as one could. The motivation to follow the clock is not intrinsic. It comes by comparing oneself with others.

Following the compass is about moving in the right direction. One could miss a promotion or a hike or a trip abroad. But there is quite some learning and most importantly there is satisfaction. The motivation to follow the compass is intrinsic. And therefore it is sustainable and one never gets fatigued soon.

Working for a small company that is cash strapped, resource constrained is an ideal set up to observe the Clock Vs Compass dilemma. Whereas one understands the unique opportunity that such a small company provides, sometimes the sacrifice made is a bit overwhelming (at least for some). People are caught up in the dilemma and eventually, some of them give in to the Clock.

In my career, it has mostly been following the compass. There have been couple of occasions where the Clock influenced me. In the long run, I realize, the clock does not matter at all. Those who went by the clock, reached first but stayed there, stagnated. Those who went by the compass, reached little late, but their journey continues. There are happy faces on either camp, but their numbers seem to be more on the Compass camp.

What I follow and what I would advice anyone is to just follow the Compass. Throw away the clock.



I did see the movie Inception. This post isn’t a review about this movie. I did like the movie and would certainly recommend it to anyone. In fact, this post can be understood better by those who have watched the movie, but not a pre-requisite.

Technological progresses have made our lives easy. At least thats what most people say. No doubt it has improved our economy, people live longer though not necessarily healthier, cures for many diseases have been found, looks like technology has an answer for everything. No not yet … wait.

I think we are nearing the cusp. Where the human being with his incredible intelligence has mastered technology to such a great extent that anything physical has been influenced by or supposedly made better by technology. The next frontier for technology is then … The Human Mind.

As Viktor Frankl mentions in his book The Man’s Search for meaning, the challenge of the future generation, as the result of technological advance, would be to combat “boredom”. “Boredom” perhaps is healthy to an extent. But what about myriad psychological problems that people would be subjected to now and in the coming years. Today, psychiatry is far less successful. The social stigma is huge. We are at a very nascent stage as far as Mind diseases are concerned.

Changes in Social fabric has put a lot of pressure and add to that the stress of job, of economy and the like. Technology lures the mind with all its offerings and the mind succumbs. Mind has so much to attend to that it gets weak, tired and for some it cracks and gives up.

In future, we would find it hard to tackle mind (or mental) problems than the physical ones. Or to put it other way, Science would advance so much that they would trace physical well being eventually to mind and start working at that. The movie Minority Report explores such a theme in the Crime prevention space (with all the dramatics).

Likewise, flexing the mental muscles would be the thing. How well guarded and trained one’s mind is ? How well it resists temptation ? How disciplined it would get ? These will be the differentiators. Mental Gyms may train people to sit in front of steaming hot, aromatic, delicious food and resist themselves from eating it … for starters!

In the movie “Inception”, DiCaprio’s plan goes haywire when the subject kind of resists the influence on his subconscious mind in his dreams. (Its another matter that Di Caprio eventually manages to have his way …)

But wait … this is what our ancients did centuries back right ? They did it in the name of religion, to “purify” themselves, to please Gods, to have self-control and so on. They went on fasting, they physically labored, some even physically tortured themselves. Were temples, Churches and Mosques mental Gyms ?

Looks like the battle with the mind cannot be won so easily !
Can technology help ?

Anyway … if you get a chance, do watch the movie. It throws open certain perspectives.

Programmer’s Dilemma


The Programmer community is often subject to many uncalled for criticisms. That they are socially challenged, that they dress shabbily, that they are more comfortable with machine than with humans, that they cant start a conversation with strangers and so goes this list. Somewhere in this list is the criticism that programmers don’t document enough.

I think there are at least three reasons why programmers are reluctant to document. But before that, let me set the context appropriately. Technical documentation can be broadly classified as documents for users (user guide) and documents for fellow developers (design doc). Programmers are OK with scribbling a basic user guide. I mean, they would be decipherable and a documentation person could convert those scribblings into a neat user guide. So far so good. Of interest in this post, is the other kind of documentation, the Design/developer documentation.

As I said earlier, there are at least three reasons that lead to this. One is a productivity oriented reason and other is habitual or behavioral and last concerns job security.

Design or developer documentation describes how the software works or supposed to work. It is written with the foresight that in future a new comer would be able to read the document and be able to understand the software better and ease his acquaintance with the software for any subsequent maintenance of the same. But the catch here is that the ultimate truth lies in the code. The Ultimate truth lies in the code and nowhere else but the code. If the documentation needs to be up to date and reflect the reality, then it should be detailed enough and abstracted to an accepted limit. But even then, it would be quite a detailed documentation. So the smart programmer thinks “In the time I take to write this document, I can as well finish the coding”. This is a very serious line of reasoning. Both documentation and coding involves the same prerequisites like clarity of thought process, sequencing of chapter/sections/programs to be written, code/document organization, modularization and so on. So there is really no motive to do the similar stuff twice. Once as documentation and again the same as programming. In fact, it is this line of thought that has given rise to tools like java doc, which apart from capturing the API contract also captures as much documentation the developer can provide so as to eliminate the drudgery of having to create detailed documentation.
OK I have written enough. To put it in a nutshell Reason 1 : Programmers don’t ( and won’t ) document because it nearly takes as much thought to code. And programmers are taught to reduce/eliminate redundancy !

The next reason is somewhat related to the previous one. Programmers just don’t read documentation. Now why they behave this way is a subject matter for another blog. But for now, take it that Programmers are too lazy to read documentation. They almost always rely on the Code editor’s intellisense and autocomplete features and meagre documentation that can be found in javadoc and the like. Given this nature, it is quite natural for the programmer to think “Why write document that would anyway not be read by any fellow programmer”.I guess this one is easy to grasp. Reason 2 : Programmers don’t read documentation and therefore, they don’t write one either !

The third reason is interesting. Complex software is really hard to understand by looking into the code. Agreed, the Ultimate truth is in the code. But many a times it turns out to be a needle in the haystack kind of a thing. Should a neat documentation exist, then it is as much easier to find the needle in the haystack. It also means that anyone could just read the document and start figuring things out. So the programmers feel that better the documentation they do lesser the job security. One way to make themselves dispensable is to write bad or no documentation at all ! Reason 3 : Bad or No documentation would make the Programmer indispensable.

In my career as programmer spanning 10 years, I have rarely come across useful developer documents (leave alone fantastic ones). This is the situation in big and small corporates that boast of smart people. Contrary to this, I find documentation in Open Source projects to be of good quality (Of course there are exceptions). This is written by the very same kind of developers (not dedicated documentationists ). Looks like there is something beyond the above reasons that could make a good developer come up with quality documentation.

Systems Thinking


As a developer and later as Architect, I have, many times had this deja-vu feeling about making some changes to the software and getting caught unaware when the change made has some impact in some other area. Sometimes the effect isn’t immediate. A fair amount of time elapses since the cause (ie., my code changes) has been introduced for the effect to take place.

Some of these have been sheer lack of adequate knowledge. But most of the times it has been a kind of reductionist approach. An assumption that the changes are local ( local to a module, say) and so it may not impact anything else anywhere. In other words, it is the difficulty in seeing the whole which leads to such problems.

I was fortunate to come across this wonderful discipline which deals with and only with seeing the whole. This discipline is called Systems Theory. The kind of thinking that leads to seeing problem and solving them by applying Systems Theory principles is known as Systems Thinking. It is about a holistic way of looking at things. These principles are so generic that it can be applied to technological as well as personal issues.

Certain kinds of problem are simple by nature or atleast certain simplifying assumptions would make it much easier to solve. For example, Newton’s Law of gravitation states that two masses attract each other in inverse proportion of the square of the distance between them. This is neatly summed as

F = GMm/r^2

[ M and m are mass of the two bodies separated by a distance r
G is a constant ]

The above discovery assumes point masses and that the interaction between point masses is to be considered in pairs. If lot of objects with various masses are around, then it is just a matter of considering one pair at a time and then vector summing their force of attraction. Such kinds of problems are classified as Organised Simplicity.

The other end of this spectrum are problems where huge numbers and random behaviour is involved. Such problems are amenable to statistical treatment. The laws of physical chemistry are good examples. The molecules are in random motion and distribution and yet certain simple laws govern their behaviour (like density, pressure etc). The qualities that make statistical treatment possible is large numbers and randomness. Such class of problems are classified as Unorganised Complexity.

But what has all these got to do with Systems theory ? Well, that is where I am coming to.

There is yet another class of problems called Organised Complexity where Simple laws wont suffice and Statistical treatment is not possible. It is such class of problems that come under the domain of Systems Theory. Some examples of Organised Complexity can be found in Biology, Economics, Computers, Social Psychology etc.

Systems Theory and Systems Thinking are helpful not only in Technical areas but also non Technical. There is lot of Systems thinking going on in Team Building, Building learning organizations etc.

I recommend the following books for further study.
An Introduction to General Systems Thinking by Gerald M. Weinberg
The Fifth Discipline by Peter Senge
Thinking in Systems – A Primer by Donella H.Meadows

Hare and the Tortoise

Since Childhood, we are all aware of this story. Hare runs faster … feels overconfident and so rests before the “Finish” line and Tortoise takes over. The moral being “Slow and steady wins the race”.

This story disturbs me a lot. From school days and now into the corporate world, every one is rushing. Immediate results are sought everywhere. Long term goals are sacrificed for short term goals in the name of being “dynamic”. Even the capable ones are known for their speed and efficiency. I can see people who are fast and have won the race and the kind who are slow but out of the race. Is it really true that “Slow and steady wins the race” ? I hardly see anyone who has been Slow, steady and in spite of that won the race.

Coming back to the story, does the Tortoise win because of its capability ? No ! The Tortoise wins because the Hare doesnt perform well. Under normal circumstances, it is the Hare that would win. So why praise the Tortoise ? Isnt this story for the “Hares” out there ? Isnt it supposed to mean “Even if you are fast it isnt enough. You have to be steady as well”.

I think thats what it is. The story is about why the Hare lost rather than how the Tortoise won.
And so the moral of that story should be “Fast and steady wins the race”.
By “Fast” I don’t mean the mad frenzy that people are into these days. Instead I mean as fast as one could practically be without being stressed or burned out. A sustainable speed and not being deliberately slow.