Thursday, July 27, 2006

When You Do Nothing Good Things Happen This is the advice of Barry Schwartz, author of the Paradox of Choice. You can see the video of his presentation at google at http://video.google.com/videoplay?docid=6127548813950043200. One the big points of his book is that "the more choices available the more likely you will choose nothing." This has enormous implications for life as we know it, but as this is nominally a programming blog, I also see it having a lot of relevance to program design. One of his recommendations to overcome the problem is to use opt-out instead of opt-in. When you ask people to opt-out of becoming organ donors, for example, you get a lot more people becoming donors. When you ask people to opt-out of joining a 401K you get a lot more people joining a 401K. The idea is that when people do nothing they get what's probably in their best interests. More people becoming organ donors and joining 401Ks are good things. How does this related to programming? At the application level we usually do a pretty good job of providing default options that give a good user experience. Can you imagine MS Windows, for example, by default providing no security and expecting the user to turn on all the security options? It would be nightmare. Oh, wait, that what they do, isn't it? Yet some default options perplex me. Why doesn't my editor by default save my changes all the time so my changes are safe from a power outage? I have to dig through 10 layers of menus to turn this work saving feature on. I usually remember to turn it on only after I have lost an hour's worth of work. So maybe at the application level we could do a better job of providing a "good things happen" experience. At the source code level good things rarely happen. Classes when created into objects usually expect the poor programmer to provide gazillions of options. The poor programmer not knowing all the options, often because of poor documentation, doesn't feel comfortable with this duty, so they may just choose to write their own code so they know they will know how the code works. Build your own is not always unreasonable behavior when face with uncertainty. A fear of not invented hear (NIH) is often blamed for people writing their own code, but that's not usually the problem. You build your own out of a healthy sense of self preservation. All the unknowns of a class/framework/system can easily seem more negative than the cost of building new. It would be helpful is more classes came out of the box with more "good things happen" automatically configurations. But programmers understandably don't want to dictate what a user should do so the usual default is to expect programmers to provide a ton of configuration. A pattern I like to get around this puzzle is to provide an abstract base class (ABC) with a "good things happen" default concrete implementation. This way the system is extensible by deriving from the ABC. All the signatures in the code use the ABC so adding new behaviors doesn't cause any code churn. And when making your concrete implementation you can provide a complete set of  "good things happen"  defaults using the logic that someone else can always create their own if they wish. If you provide good documentation for the options, the ability to see what the options are, and accessors to set the options, maybe your concrete class will be all that's necessary. By using factories you can extend this idea to provide "good things happen" for many different scenarios in your program. The ideas in The Paradox of Choice on the debilitating role of having too much choice probably have wide and interesting implications in system design. comment[] 1:26:58 PM

© Copyright 2006 todd hoff. Last update: 7/27/2006; 1:27:08 PM.