Wet monkey theory

You put n monkeys in a cage with a banana (or any food that is of interest to the monkeys) and for some defined period of time discourage the monkeys getting to the fruit by splashing them with cold water till none of them attempt to reach for the fruit. Now, one by one replace the monkeys over a period of time where the monkeys will not be splashed with cold water at all. Now, because of classical conditioning each of the new monkeys that will instinctively reach for the fruit but will be beaten up (or otherwise restrained) by the remaining monkeys by the fear of punishment in the form of a cold water splash. Subsequently, when none of the original n monkeys are in the cage and the ones that are there have never been subjected to the punishment, it will be observed that none of those monkeys try to reach for the fruit in fear of retribution by the other monkeys.

The wet monkey theory seems more of an urban legend than an actual theory. Its actually based on the famous Pavlov's salivating dog experiment on classical conditioning. The little Albert experiment is perhaps the closest human counterpart. But, apart from that there are several examples of this in real life.

Especially, in large software development shops where you have every kind of programmers (all of the 26 programmer predilections-link doesn't seem to exist now so, heres a digg posting of the same), all the 3 types of consultants and hordes of PHB's. The reasons why a particular approach/technique was chosen over others is often lost when the pioneers of the system leave or is buried in huge mounds of documentation. Now, documentation is always an icky subject when it comes to software systems the people who are in the best position to do it despise it with a vengeance and the ones that do write it (or are forced to write it) usually cover it up in layers of cruft to make the document appear important than it actually is. Signal to noise ratio in documentation is alarming low, the concept of code as documentation does not stand to reason if you have a half a million lines of code to read!! (notwithstanding the fancy design patterns and xml configurations distributed liberally over the codebase) All this leads to any question on anything is answered by thats 'the way its always been done'.

One way to bite down and bear it to turn to the Tao of Programming and rest on the wisdom of the ancients before us.

The programmers of old were mysterious and profound. We cannot fathom their thoughts, so all we do is describe their appearance.

Aware, like a fox crossing the water. Alert, like a general on the battlefield. Kind, like a hostess greeting her guests. Simple, like an uncarved block of wood. Opaque, like a black pool in a darkened cave.

Who can tell the secrets of their hearts and minds?

The answer exists only in Tao.