Angry monkeys and other stories

First, a story contained in The Productive Programmer, which I find really interesting and helpful. Neither I nor the author know if the story is real, but it has a powerful moral. Telling a story is often the best mean to communicate an interesting concept.

Angry monkeys
Once upon a time, there was a group of scientists who were experimenting on monkeys. They placed some of them in a closed room, along with a ladder that allowed them to grab a bunch of bananas hanging from the ceiling. The catch was - whenever a monkey went near the ladder, cold water was sprayed in the room. What the scientist get as the result of this experiment? Angry monkeys.
Then they remove one monkey from the group, and put in a brand new animal which was not aware of the cold water trap. His instinct suggested him to climb the ladder... Only to be suddenly beaten up by the other angry monkeys, which were tired of the cold feeling.
Continuing the experiment, they replaced one more monkey, and one more, until they have in the room only animals who have never experienced the cold water trap, which was now turned off. But still, if a monkey approached the ladder, he would have been stopped and beaten by his companions.
The moral is: why some practices are followed today? Because if they were not, a bunch of angry monkeys would yell at you. Some examples?

• Primitives in Java, supported because it was very strange to create classes for simple values (now recognized as immutable Value Objects).
• Making every entity class a bean or an Active Record was common practice between angry monkeys, but the situation has changed in the last years.
• constructors that perform real work, or that even creates other objects, because someone thinks that object-oriented programming means writing programs consting only of the line new ApplicationInstance().

Sometimes a standard is enforced because it provides consistency and interoperability; some other standards are relics of the past, craved by angry monkeys. Dare to not always follow the same road of others.

Here are similar software stories, in the form of fables. The power of metaphors allow us to explain software problems even to naive people.
How to kill a dragon? This is something many knigths would want to know. And what if they could use their preferred programming language to complete the quest?
In Deadline and Technical Debt, a valorous knight attempts to satisfy the requests of the king to marry his daughter, the princess Caroline. Will he be successful?
The Stone Soup story, reported also in the original Pragmatic Programmer book, teach us that people find easy to join an ongoing project and this is a powerful way to cooperate.