Six vs. Twenty-Four Jams: Too Many Choices

As much as I have fond remembrances of Perl, I'm glad languages like Python are around. As I mentioned in a previous post, one of the reasons I left Perl behind was TMTOWTDI. Note the reference in this Wikipedia article to the Python principle that espouses the opposite philosophy. I've now found more support for the idea that more is not more, and is sometimes less.

I've read a few articles that cited a study where consumers were presented with different numbers of choices for buying jam. Searching for those terms turned up this article. I found it interesting that more choices made more people stop and look, but more choices reduced the number of people that actually bought any jam. I, like many others, like to feel that I know enough to make an informed choice. I also realize, however, that I am just as happy to have someone (who I hope is more knowledgeable than me) winnow down those choices to a set to which I can actually give decent consideration. This also reduces the time required to make a choice.

I know that for Perl, once I figured out how to do something, I actively rejected trying to find other ways to do that same thing. I never felt the need. I also never had a case where performance was an issue (which would have forced me to look at other ways). I also, thankfully, never had a Perl prophet try to convert me to the "Many True Ways" of Perl.

This also makes me think of all the sales vice presidents that have touted their "pipeline," but weren't able to translate that into actual sales. It's the end result that matters (both the quality of that result and how long it took to get there), whether you're on the making, selling or buying side of things.