Since seeing Barry Schwartz’s presentation to Google on The Paradox of Choice I have been struck by how often his words ring true.Give people more choice and they are less likely to make a decision and more likely to feel worse about their decision if they do make one.

“Everyone agrees that having choice is better than not having choice. It seems evident that if choice is good, then more choice is better. The paradox is that this “obvious” truth isn’t true. It turns out that a point can be reached where, with more choice, people are worse off.”

In an old interview (Jan. 2005) Mark Hurst of Good Experience asks some questions of Schwartz that illicit some interesting notions of online commerce (among other things). Here’s something to illustrate this point:

Q - I know you’re interested in getting a major e-commerce site to try an experiment on the home page.

Yes, to illustrate my general view. Take any of the most commercially successful websites - Amazon.com, for example - and look at what they offer. Click Bestsellers; down come 20. My view is, when people look at 20 book titles, each of them is competing with the others, making the others less attractive. This one looks exciting, this one looks educational, this one is about my own childhood, but this one is exotic and will take me into a world of imagination. Each is attractive in some way.

The result is that you look at 20 and buy none. But what if Amazon did a simple experiment of not showing 20 books, but only the top five? You can always click to the next screen and see more. My prediction is that if you reduce the choice set, you increase the number of books sold. This should be true of anything you’re selling - office chairs, CD players, vacation packages; the shorter the list, the more attractive the items on the list will be.

It is interesting to note that this already working in the “real world” at Costco, where there are only a few brands/items represented for each product segment. Yet, Costo customers are among the most satisfied of all retail shoppers.

Try telling the Director of Marketing or the CEO that your homepage shouldn’t have links to everything on your site and you will see just how strong an idea is “more choice is better”. Choice is good, then obviously more choice is better. One of my favorite examples from Schwartz’s presentation (and likely his book of the same name) involves buy jeans. At one point, to buy jeans, you simply went to the store and bought the jeans that were your size - one choice, size. The brand (Levi’s), color (blue), and style (basic) were all more or less determined for you. If you got the jeans home and they were ill-fitting it wasn’t your fault, it was Levi’s fault. Now if you go and get an ill-fitting (or unstylish, etc.) pair of jeans (why is it a pair?) it is obviously your fault because there were so many choices there had to be one that was right for you but like an idiot you didn’t take your time with the decision.

It is a long presentation but well worth it. If you have to skip around, I recommend the segment on the default assumption for society and how to live near the 13 minute mark, about how most people now spend a lot of time on things that were non-decisions years ago.

Barely related: On MPR or NPR I heard a story about how optimistic people tend to be the ones who develop road rage while driving because their expectations and reality do not mesh. An example of this (me) is that despite commuting the same way each day and there being traffic and bad drivers, each day, I still somehow expect there not to be, causing me frustration and anger. A better approach, just set my expectations more realistically. (Note - I do this with sports too - I think every sport I play I should be able to play at a high-level, causing me to get frustrated with myself if I cannot.)

Nat Pryce has a good post about interviewing programmers. Everyone that I’ve talked to has the same problem: How to figure out if a programmer is any good before you hire them. A similar problem exists in just hiring people in general, but this is the more specific problem of determining skill level.

Some people can talk a good game without actually being able to think through a problem to a logical and feasible solution. Others can walk through a hypothetical example at a whiteboard with ease or explain in detail how and when to use inheritance vs. delegation. These same people, however, may not be at all capable of tracking down how to fix a coding defect or how to add new functionality to an existing codebase. Ultimately, you really don’t know much about their actual skills until you see them code in a real environment. I think that Nat has a lot of good ideas here.

In my own experience on a smaller team, we’ve had good luck with getting referrals and checking references as a start. Then we interview and if we decide they seem like a fit, we bring the developer in as a contractor with a hire clause. That way, if they work well in our team we can bring them in full time. The interview process ends up being what I expect is pretty typical, but we start all of our developers as contractors. This lessens the hiring burden and gives us some time to figure out if the person is a fit for our team. It’s not perfect, but like I said, we’ve had pretty good luck with it. We haven’t had any pushback from our developers on this stance either. Most don’t seem to care of they are full-time employees or contractors. In some instances, candidates have asked that the hire clause be removed because they had no interest in a full time position.

Another thing that originally interested me in Nat’s post about interviewing was the comments. Since interviewing and hiring is a problem that everyone faces, I’m interested hearing what others have learned about hiring developers over the years. Regardless, I plan to start incorporating some of Nat’s ideas in my next interview.

Another problem that agile teams face is making sure that the developers understand the customer and/or the business. Along those lines, Martin Fowler has a good post about what he calls Customer Affinity: The ability for developers to really get involved with the customer and maintain a two-way conversation about software. I’m not sure of a good way to interview for this, but our current approach of contract-to-hire allows us to get somewhat into this before a hire decision must be made.

Somewhere between the long nights troubleshooting the CSS and XHTML for the new Alt Text and the creation of not one or two but three lists of tasks that needed to be completed for the site to be “just so” I mentioned to Jesse the things I still needed to do before I launched. He told me something interesting, and off-handed. He said “Just launch it, that’s agile baby.” Now I may be paraphrasing a bit but that is the gist. I laughed him off, thinking that launching a half-finished redesign of my personal blog is not really what the agile method is all about. But as it turns out Jesse was right. I finally did allow many of the tasks on my list to flow onto the “after launch” list and even some big ones to be open for public help. The way I looked at it, the new design represented a pretty big improvement (even with the bugs) over the older one and I just needed to get it out there.

It turns out Guy Kawasaki would agree. I am currently reading his last two books:The Art of the Start and Rules For Revolutionaries and there is a lot of similarities with what he is saying and what folks like 37signals are preaching. Kawasaki tells us in Rules for Revolutionaries that we shouldn’t fear shipping an imperfect product…

Revolutionary products don’t fail because they are shipped too early. They fail because they aren’t revised fast enough.

He goes on to quote Winston Churchill:

To improve is to change, to be perfect is to change often.

Although he calls it churn, Kawasaki is really talking about constantly changing and refactoring your products be better. He illustrates the Japanese model as it contrasts with the traditional American way:

American:

Concept –> Engineering –> Marketing –> Customer

Japanese:

Concept –> Engineering –> Customer –> Churn (repeats as a circle)

You must plan for change and embrace it in your products life cycle. Furthermore you should change your product for your users, not for your non-users. This may seem to make sense but many companies ask, “What would our product need to have in order to increase market share?” That is the wrong question. A better question would be “what do our user’s need to make their lives easier?” or “how can we allow our customers to use our products less?”

Though only somewhat related to this post, Guy Kawasaki’s The Art of the Start presentation this past May at TiECon is worth checking out.