Jim Cushing's Blog

The Paradox of Choice

A recent book, The Paradox of Choice: Why More is Less by Barry Schwartz, has been getting quite a bit of attention lately. In it, Schwartz contends—and his research backs this up—that people are frequently less satisfied as the are offered more choices.

I tend to believe he's right. The Java world alone offers plenty of anecdotal evidence. For instance, after occasional frustration with Eclipse's quirky slowdowns, I decided to give JEdit a try. Out of the box, JEdit has a fairly basic feature set, but the vast selection of plugins is its selling point.

So I downloaded JEdit, after deliberating a moment on which download site to choose (Hmm, Ibilio is closest, but I wonder if Aleron will be faster? What about U. of Minnesota?). Not long after, I opened its Plugin Manager. Dozens of plugins are available for essential features I had grown to count on Eclipse for, such as version control, code completion, code formatting...you name it. For any given piece of functionality, there frequently was not one or two, but three or four, plugins available. But which were the best? Which would work the together the most smoothly? Or, which ones would remain perpetually at version 0.x.y as the authors, themselves awash in a sea of choice, decided to focus their attention elsewhere?

I tried JEdit for a few hours, maybe even a few days, but I had this nagging feeling that I just wasn't using the right set of plugins; surely if I explored a bit longer, I'd find the ideal combination. But, I had work to get done, and I returned to my comfortable world of Eclipse, using mainly the out-of-the-box features.

I've had success with ObJectRelationalBridge, aka OJB (speaking of choices, surely, one would think, they could have chosen a more natural acronym), though it, too, can overwhelm with its set of choices. Three different persistent APIs: ODMG, JDO, or its own PersistenceBroker API. Configurability galore! Pick your transaction manager, your connection factory, your caching implementation, things you didn't even know you needed to know! To be fair, you could (and I largely did) use the default settings, but still, I never knew that I was using the optimal configuration, and this bugged me. And was OJB even the right choice? Would I have been better off using on of the many other O/R frameworks?

When I was fairly new to Java, I had a coding habit that could best be described as "overloading overload". I'd provide oodles of constructors, for each permutation of parameters a class might take. I'd overload methods to provide the ultimate in flexibility and convenience, or so I thought. So many choices, there's bound to be one to fit your needs! Now, it's up to you to determine which choice to make.

But developers don't necessarily need more choices, we need more answers. I don't know "PersistenceFieldClass" I should choice, or which caching implementation is best. I want to let OJB decide for me precisely because I don't want to get bogged down in the details of implementing an object-relational system. You guys are the experts so I don't have to be.

An embarrassment of riches when it comes to APIs and ways to solve the same problem leads to confusion, which leads to the need to define "best practices." We want to feel we are following these best practices, but with some many choices, how do we know if we've made the right one? We prototype, we benchmark, we agonize out of fear that we're made a sub-optimal decision.

Even talented developers need a little nudge in the right direction from time to time. Not ever problem as "the one true solution," but not every one needs an API-cornucopia, either. Sometimes, it pays to do one thing, and do it well.

Incidentally, excerpts from Schwartz's book are available at any of the following links. Take your pick:

• Hopkins & Company
• Harper Collins
• God Spy
• USA Today
• USA Today (Printable version)
• Scientific American

Comments

• Beyond choice to competing defacto standards
  What drives me nuts is the 734 different products that do related, often overlapping, things.

  Springs, Struts, Hibernate, EJBs, JDO, XPath, XSLT, JMX, GodKnowsWhatElse, JDBC.

  Yes, most of these are a little to a lot different, but there's so damn many of them and so many employers want you to be an expert in whatever particular combination they use.

  This feels like fragmentation: too many ways to accomplish similar goals. Plus, tools are replaced by the next great thing so quickly. I work for a living :), so it's hard to keep up on the thousands of open source projects that might possibly be the wave of the future (until the next thing comes along a year later).

  
  I'm not sure what the answer is, if any. It's nice to have choices, but you have to research and understand them to make an intelligent decision. When it takes you as long to research all the tools than to just build the damn thing with any random tool, I'm not sure what value there is in having so many choices.
  

  Posted by: ckessel on May 20, 2004 at 07:53 AM

• Hey! I called Barry Schwartz first!
  I mentioned his article myself a while back, and it's a recurring theme in my editorials lately. :)

  Posted by: epesh on May 20, 2004 at 08:06 AM

• Beyond choice to competing defacto standards
  I'm not sure what the answer is, if any. It's nice to have choices, but you have to research and understand them to make an intelligent decision. When it takes you as long to research all the tools than to just build the damn thing with any random tool, I'm not sure what value there is in having so many choices.

  The answer is Windows and .NET, of course, where you have little choice but good integration. The lack of choice simply helps make this solution a safe platform to choose, backed by a moderately focused push from Microsoft. .NET, C#, SQL Server. Done, now we accept our choices, move on and make it work. No need to second guess yourself, or have other second guess you.

  On the one hand, we have some strong defacto standards in Java, for example using Ant builds. Using the generic Tomcat Application as a basis for structuring a new webapp is a great head start on any project.

  Some are bubbling up to being common and prevalent. I think Hibernate has more mindshare in OSS than JDO for example, and Struts and Velocity seem extremely popular.

  The darkside is seeing hard drives filled with frameworks, but not new code as people are paralyzed by "making the right choice", which is even more difficult if you're a beginner.

  Look at JSPs for example. How hard could it be? JSPs. Easy. But no, you have JSPs, JSTL, JSP 2.0, JavaFaces, etc. etc. etc.

  Where To Begin.

  I think its time folks start bundling pieces together, with good examples, as a solid "good practice" single source. Say, Ant, Struts, Tomcat, Spring, Hibernate and Velocity. Preconfigured template app, solid example to cut-n-paste code from, preconfigured servers and all of the libraries. Anyone grabbing that suite of stuff will be able to hit the ground running and start coding with the major infrastructure choice already made and integrated. Lots of patterns in the sample app, just fill in the blanks and go, essentially copying bits you may not understand from Stuff That Works.

  That lets good habits be picked up by new users withouth necessarily having to understand that they're good habits. It lets them get a completed puzzle from the get do without having to ponder each piece.

  When they learn enough to start being picky about things, they can change whatever they want. But then they may find that the choices they have aren't so bad and decide not to change after all.

  Posted by: whartung on May 20, 2004 at 04:15 PM

• Beyond choice to competing defacto standards
  I think its time folks start bundling pieces together, with good examples, as a solid "good practice" single source. Say, Ant, Struts, Tomcat, Spring, Hibernate and Velocity. Preconfigured template app, solid example to cut-n-paste code from, preconfigured servers and all of the libraries.

  Interestingly, there is something that offers exactly that: AppFuse.

  Posted by: jimothy on May 20, 2004 at 04:51 PM

• Beyond choice to competing defacto standards
  Now, I haven't actually read the book yet*, but I learned of the book from The Tyranny of Choice, an article in Scientific American. The point that Schwartz makes is how, counter-intuitively, and abundance of choices makes us less satisfied with our decision, and that people who tend to spend a lot of time carefully considering a decision are more likely to be dissatisfied with their choice. Schwartz calls those strive to make the best possible choice maximizers while calling those who go with "good enough" satisficers. His research shows that satisficers tend to be happier with their decisions.

  The subtext of this is, don't spend so much time evaluating every possible choice; not only will you get the actual work started more quickly, but you're likely to be more satisfied with your decision (or, at least less dissatisfied).
  To use OJB as an example yet again...I was asked why I used OJB on a project over, for instance, Hibernate. I had a few reasons why I preferred OJB, but you know what? I had to make some decision. At some point, it really is arbitrary. The project would have been just as successful with OJB or Hibernate (though I do believe using O/R resulted in faster development time, and cleaner code; but which O/R framework is of lesser importance).

  I used to be an unquestionable maximizer; but slowly, I've learned there are times that call for me to be a satisficer.

  * By yet, I mean, I probably never will, but I feel ashamed to have posted a blog about a book I haven't read, so I better make it sound like I'm going to do so real-soon-now.

  Posted by: jimothy on May 20, 2004 at 05:18 PM

• Hey! I called Barry Schwartz first!
  On java.net? It's too bad we can't match "posters" with "bloggers" here. Reveal yourself; i'd be interested to see what you had written.

  Posted by: jimothy on May 20, 2004 at 05:19 PM

• Beyond choice to competing defacto standards
  Perfect. Exactly what I was thinking of. Things like this need to be more publicized, IMHO. Choice is good for those capable of making the choice, but not everyone who wishes to leverage these systems are necessarily confident or qualified enough to make those choices upfront.
  

  Posted by: whartung on May 20, 2004 at 06:32 PM

• Capitalism vs Communism
  Does anybody realize that VisualStudio still does not support refactoring? You can spend about $2K and get crap. Yes, VisualStudio is well-integrated, general use tool, but it’s crap. It’s slow, large, takes about 1GB of memory to run correctly, missing features, the developers have to hunt and peck to find stuff.

  Why? No competition. I would rather have too many choices then the alternative.

  [ How do I know about VisualStudio as a Java developer? I’m teaching 00 techniques to C# developers, and I’m working inside the tools. Nant is missing so many features that the C# team use Ant for builds. ]
  

  Posted by: malcolmdavis on May 20, 2004 at 09:10 PM

• Capitalism vs Communism
  for C# there's a solution: www.intellij.com -> ReSharper. If you know the (excellent) java-IDE of IntelliJ you won't hesitate to give it a try

  Posted by: mreasy on May 21, 2004 at 02:15 AM

This work is licensed under a Creative Commons License.