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