karenika - books - the pragmatic programmer

The Pragmatic Programmer

Stone soup and boiled frogs

The three soldiers returning home from war were hungry. When they saw the village ahead their spirits lifted rred the soldier boiled a pot of water and carefully placed three tones into it. The amazed villagers came out to watch.

"This is stone soup," the soldiers explained. "Is that all you put in it?" asked the villagers. "Absolutely - although some say it tastes even better with a few carrots." A villager ran off, returning in no time with a basket of carrots from his hoard.

A couple of minutes later, the villagers again asked, "Is that it?"

"Well," said the soldiers, "a couple of potatoes give it body." Off ran another villager.

Over the next hour, the soldiers listed more ingredients that would enhance the soup: beef, leeks, salt, and herbs. Each time a different villager would run off to raid their personal stores.

Eventually they had produced a large pot of steaming soup. The soldiers removed the stones, and they sat down with the entire village to enjoy the first square meal any of them had eaten in months.

There are a couple of morals in the stone soup story. The villagers are tricked by the soldiers, who use the villagers' curiosity to get food from them. But more importantly, the soldiers act as a catalyst, bringing the village together so they can jointly produce something that they couldn't have done by themselves - a synergistic result. Eventually everyone wins.

Every now and then, you might want to emulate the soldiers.

You may be in a situation where you know exactly what needs doing and how to do it. the entire system just appears before your eyes - you know it's right. But ask permission to tackle the whole thing and you'll be met with delays and blank stares. People will form committees, budgets will need approval, and things will get complicated. Everyone will guard their own resources. Sometimes this is called "start-up fatigue."

It's time to bring out the stones. Work out what you can reasonably ask for. Develop it well. Once you've got it, show people, and let them marvel. Then say "of course, it would be better if we added" Pretend it's not important. Sit back and wait for them to start asking you to add the functionality you originally wanted. People find it easier to join an ongoing success. Show them a glimpse of the future and you'll get them to rally around.

The villagers' side

On the other hand, the stone soup story is also about gentle and gradual deception. It about focusing too tightly. The villagers think about the stones and forget about the rest of the world. We all fall for it, everyday. Things just creep up on us.

We've all seen the symptoms. Projects slowly and inexorably get totally out of hand. Most software disasters start out too small to notice, and most project overruns happen one day at a time. Systems drift from their specifications feature by feature, while patch after patch gets added to a piece of code until there's nothing of the original left. It's often the accumulation of the small things that breaks the morale and teams.

We've never tried this - honest. But they say that if you take a frog and drop it into boiling water, it will jump straight back out again. However, if you place the frog in a pan of cold water, then gradually heat it, the frog wont notice the slow increase in temperature and will stay put until cooked.

Note that the frog's problem is different from the broken windows issue discussed in Section 2. In the Broken Window Theory, people lot the will to fight entropy because they perceive that no one else cares. The frog just doesn't notice the change.

Don't be like a frog. Keep an eye on the big picture. Constantly review what's happening around you, not just what you personally are doing.

I would have originally said that this book is a good first resource to people interested in application development, especially in a group environment and for a client, but I think unless you've worked, you would find this book totally useless. And even if you have worked, you might think it's little less than common sense. I learned nothing new from the Pragmatic Programmer, but I liked the tone of the book, the ideas presented, the anecdotes and quotes and the compactness of it. I also agree with most everything mentioned in it. If you work with people who don't come from a practical computer science background, this is a worthwhile book to send in their direction.