Thursday, May 28, 2009
This experiment placed five monkeys in a room with a banana tree in the center. Whenever a monkey attempted to climb the tree to pick banana, a sprinkler system would spray all the monkeys with water until the monkey retreated from the tree. They repeated this experiment until all the monkeys learned to not approach the tree. The monkeys liked being dry more than they liked bananas.
The next stage of the experiment involved replacing one of the monkeys with one who had never been sprayed with water. The new monkey soon started to approach the banana tree. However before the sprayers started, the other monkeys jumped into action and beat the new monkey away from the banana tree. This was repeated every time until the new monkey learned not to approach the tree.
The researchers continued to replace the original monkeys who were sprayed with water one by one with fresh monkeys. Eventually none of the monkeys in the room had ever been sprayed with water for climbing the banana tree. The monkeys still continued to beat up any monkey for approaching the banana tree. None of them "knew why” they couldn’t approach the banana tree. They just knew that the banana tree was off limits.
Sometimes we developers do the same thing. A company’s culture becomes intertwined with the “standard best practices” that aren’t questioned and never replaced. Personally I did this for many years pursuing waterfall methodologies. I wrote big documents up front (BDUFs) for projects that always failed to account for everything. Even after those projects shipped--following months of crunch and despair--I would start the next project the same way.
Are there any "banana tree" rules where you work?