Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.
In his book The Paradox of Choice (Harper Perennial), Barry Schwartz cites a study showing that users are paralyzed by too many choices. Rather than being happy that they have lots of choices, too many choices make them uncomfortable. For example, there was a store that sold jam, and to allow customers to sample their wares, they put out a table with three jars of jam. Sales of jam skyrocketed because customers liked being able to taste the jam before they bought it. Using logic, the proprietors decided to put out 20 jars of jam for tasting. And the sales of jam plummeted. Having three jars was good because people liked to be able to sample. But having 20 jars became overwhelming. People still sampled jam, but there were so many choices, it paralyzed their decision-making process, leading to fewer jam sales.
We software developers have the same issue when it comes time to solve a problem: there are so many ways to attack it, we are sometimes prevented from even starting. For example, in the SqlSplitter example created to bust SQL files into smaller chunks cited in Section 4.12” (Chapter 4), the developer with whom I was pair-programming initially thought about using sed, awk, C#, and even Perl to try to solve the problem, but quickly realized that it would take too long. Given the number of choices we have, how do you pick?