New Look for the Blog

I switched up the theme today to get a wider region for the writings. I did this in the hope that it makes some of my longer postings a little easier to read. Please let me know if it is now easier, harder, or no change at all.

Also, just after switching the theme I ventured over to Davin’s blog and noticed that we both are using the same theme. Great minds do think alike!

Using (return val of) member function as default parameter of member function

C++ allows the programmer to do some really cool things. When writing code I try to follow the Google C++ Style Guide, so I haven’t gotten much experience with the fringe areas of default parameters. A question was recently asked on the comp.lang.c++.moderated usenet group where the OP wanted to place a member function as the default argument, a la:

class foo {
 int getInteger();
 void doSomething(int i = getInteger()) { }
};

Many of the responses said that he should overload doSomething as a nullary function and call the original doSomething with the return value of the member function. Within most of these comments was one from Neil Butterworth, who mentioned that the reason this isn’t possible is because the this pointer is not available until the body of the function. He offered that the OP could make getInteger a static function.

class foo {
 static int getInteger();
 void doSomething(int i = getInteger()) { }
 };

And if you don’t believe him, you can use the Comeau C/C++ Online Compiler to see for yourselves.

I thought this was really cool. While I may not have a use for it at the moment, it is questions like these that are great conversation starters. About a month ago I subscribed to the clcm mailing list and I now recommend it to others as a way to learn different uses of C++ and interesting conversations about the language.

Why Head and Shoulders Has Less Variations For Sale

Not too long ago, Proctor & Gamble marketed Head and Shoulders shampoo with twenty-six variations. Sales were good, but not maximal. To increase sales of their shampoo, they decided to reduce the number of variations from twenty-six to fifteen. Result: Sales increased 10% [1].

But does that make sense? Popular notion would seem that the more choices an individual can make, the happier they will be. Don’t you like to have the option to choose between a small, medium, large, or extra-large drink? It turns out that the popular notion isn’t wrong, sometimes it’s just applied at the wrong times.

When given the option to choose, increasing the number of options from 2 to 6 increases the satisfaction of the individual and reduces the amount of time to make said decision [1]. But at what point does the addition of options have diminishing returns? George Miller, a cognitive psychologist at Princeton in 1956, found that the optimal number of choices are 7, plus or minus 2 [2].

This 7 ± 2 rule has been widely cited, and it may be the reason that many fast food restaurants have pared down the number of value meals that are offered to fit within this range. When the number of options is higher than 9, individuals will feel overwhelmed and burdened by the worry that comes with making a “wrong” choice.

Residents of the United States are faced with so many decisions on a daily basis, including decisions that are likely to affect loved ones, that the decision-making process becomes demotivating [3]. Up to this point (2000), there has been research that focused on the 7 ± 2 rule, options ranging from 2 to 6, but no research on options ranging in count from 6 to 24 or 6 to 30.

A study by Sheena Iyengar of Columbia University and Mark Lepper of Stanford University specifically looks at the effects of choice and has interesting findings. Iyengar and Lepper performed three studies observing participants initial reaction, satisfaction, and decision-making when presented with extensive and limited selections.

One of their studies focused on the sale of exotic jams. They stationed a sample booth in a gourmet grocery store and offered varying numbers of jam to sample. If a customer approached the sample booth, they received a coupon towards a jam, and purchases of the jam were recorded to determine the effect of the sampling booth.

Table 1

Extensive Selection	Limited Selection	Total
24 flavors	6 flavors
386 shoppers	368 shoppers	754 shoppers
242 encountered	260 encountered	502 encountered
145 stopped/sampled	104 stopped/sampled	249 stopped/sampled
4 purchased	31 purchased	35 purchased

Those results show the following percentages:

Table 2

Extensive Selection	Limited Selection
66% encountered	63% encountered
60% stopped	40% stopped
3% purchased	30% purchased

These results are very interesting. Although the number of customers that approached the extensive selection (60%) was much higher than the limited selection (40%), these customers did not purchase the jam. In fact, the customers that approached the limited selection were 10 times more likely to purchase.

Given those percentages, can we turn the data on its head and determine the effect that the number of flavors presented had, given that the customer was going to purchase the jam?

To answer the question, we can use the naïve Bayes theorem [4]. The naïve Bayes theorem provides a way to find the posterior probability given a pre- and post-condition. We can use the percentages given in Table 2 and apply them to the theorem:

The probabilities for purchasing without sampling were  not given, and thus we will use a weighted average of the purchasers to estimate the probability at 0.095 ((4/386) + (31/368)). These numbers are chosen because we will have to assume that regardless of the number of flavors present at the sample booth, these customers were already going to make a purchase. Ideally, we would have in our data set the number of customers who purchased regardless of stopping at the sample booth.

P₆(sample|purchase) = (P₆(purchase|sample) * P₆(sample))/(P₆(purchase)) = (0.3 * 0.4)/0.095 = 1.26
P₂₄(sample|purchase) = (P₂₄(purchase|sample) * P₂₄(sample))/(P₂₄(purchase)) = (0.03 * 0.6)/0.095 = 0.19

Using the naïve Bayes Theorem, we are able to find that when customers were buying jam, they were 663% more likely to stop and sample jam if the sample booth only contained 6 flavors compared to 24 flavors. The increase in choice may have at first glance brought many more customers to the sample booth, yet the customers that approached the booth when 24 flavors were presented may never have intended on purchasing the jam.

So Miller’s rule says that 7 ± 2 is the right number of choices, and Iyengar and Lepper make a case that happiness does not increase with choices. Right now, we are encountering too many choices. Most of us would probably choose the same options, so we might as well be happier about our choices. Therefore, if our goal is to make the customer happier, the selection should be limited before they encounter their decision. In the end, we will all be happier.

[1] http://www.columbia.edu/~ss957/articles/Choice_is_Demotivating.pdf
[2] http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two
[3] http://www.ucpress.edu/books/pages/5572001.php
[4] http://en.wikipedia.org/wiki/Naive_Bayes_classifier

StackOverflow DevDays Toronto Recap/Review

It seems a little late to write my review of the StackOverflow DevDays conference I attended in Toronto on October 23rd, but I had said that I was going to put it up here. This is me backing up my word.

The conference had six talks, including the opening keynote. Of the six talks, I felt three could have been left out. The whole conference took place in one large theater, meaning there was no choice of talk to attend. Given that, the language/framework overviews of ASP.net/MVC, Python, and jQuery all were pretty boring. I’ve used all three of them before, and all the talks felt redundant (to me). I think that had it been a conference where you could choose which session to attend, then these talks could have had a lot more value.

The three notable talks were those given by Joel Spolsky (co-founder of StackOveflow), Greg Wilson (Associate Professor in Computer Science at University of Toronto), and Reginald Braithwaite (Software Developer and Development Manager).

Joel Spolsky’s Opening Keynote

Joel Spolsky’s keynote was all about writing software with less features and simplicity. He mentioned a study where researchers had customers of a grocery store sample either 6 different flavors of jam or 24 different flavors. When 6 flavors were offered, 40% stopped and tried some. When 24 flavors were offered, 60% stopped and sampled. Yet the interesting twist comes from who purchased. The 6-different group had 30% of the stores customers (not just the ones who sampled) purchase, while the 24-different group only had 3% purchase. He draws the conclusion that too many choices just complicates things and people get intimidated. (I’d like to get access to this research. If anybody knows the publication, please let me know in the comments Update: I just got a link to it: When Choice Is Demotivating).

The main point of the talk is that we should have less features and less choices. Joel mentioned that:

Too often we developers ask users to make decisions that they shouldn’t need to. We tell them, “don’t hit the back button”, “how many items should show up in a recently used list?”, “continuing will cancel your appointments. should i cancel your appointments? [ok] [cancel]“.

Users do not want a dialog with their software, they just want to get stuff done. They don’t want to be interrupted while giving a presentation, or when there is a time crunch and the software pops up to tell them that an update is available.

One of the scenarios he brought up when explaining the need for less dialogs is of a CFO and her secretary. The CFO was cheating on her husband with her secretary and one day out of the blue her husband walks in to the office. The CFO panics and her secretary turns to face her. He says pay me now or I tell your husband. She obliges and opens up QuickBooks (with only a minute to spare before her husband walks in) and then QuickBooks tells her that she has an update pending. That update dialog is the last thing she wanted to see.

Greg Wilson – Professor at University of Toronto

This was an awesome talk. Most of the talk centered around how people within the computer science field are too willing to take data and new methodologies at face value without digging in and calling people’s bluff. He also jumped around and brought up the lack of women in Computer Science and code quality as it pertains to a company’s organizational chart.

When talking about taking new methodologies at face value, he says that none of the facts that argue for Agile have been proved and those following Agile are just the blind leading the blind. For an example, he cited the quote “The best programmers are 28 times more productive than the worst.” The study that originated that quote is heavily cited, yet looking deeper in to the study, it can be seen that we shouldn’t take at face value all these statistics. It turns out that the study was conducted by observing 12 programmers for one afternoon. Even then, what does it mean to be more productive?

He also talked about the need for more women in computing, and the Dweck Effect that is happening. He recommended reading the book, “Why Aren’t More Women In Science?“. (I’ve added it to my want-to-read list).

We as developers need to be humble. This does not mean bowing down to our bosses. It means if we are screwing up, admit it, fix it, and move on. We are not the best developers in the world, we do write crap code, and we need to be honest. He also brings up that code reflects the organizational chart of the company. If two people have different managers, they will be pulled in different directions and the code will show.

Reginald Braithwaite – Software Developer and Development Manager

Reginald Braithwaite was introduced by Joel Spolsky as one of the smartest people that Joel knows. Reg is known from rewriting Ruby to include Lazy Evaluation and Extension Methods. Very little of the talk focused on Ruby, and more about how we are “thinking about thinking about programming“.

He says that you should organize your code as though you are creating a presentation or writing an essay. If there is a large amount of code that does not matter, you should look at abstracting it out or fixing it.

Throughout the talk, he continued to drive in the point that we should think about thinking about programming. We will run in to a problem that appears hard to solve. There is a way that it can be made easier, and we might need to take a step back. “A programming language is just a notation of thought. A programming language can tell somebody how the developers who use that language think.” We should be saying, “What is the way that I should be thinking about solving this problem?”

To give an analogy, he brought up a Winston Churchill quote where he said that he was at a bar and a young lady came up to him and called him a drunkard. In reply he said, “Yes, and you are ugly. But in the morning I will be sober.” The point of that quote is that, “if there is a limitation, don’t accept it as an ugly problem, make it a drunk problem.” No problem is impossible, you may just be thinking about solving the problem wrong, and you should be thinking about how you are thinking about solving the problem.

In closing, he gave an Alan Perlis quote: “A language that doesn’t affect the way you think about programming, is not worth knowing.”

Those three talks were well worth the trip from Okemos, MI to Toronto, Ontario. I’m looking forward to next year’s StackOverflow DevDays. Will I see you there?

Now on Twitter

In the pursuit of writing my next blog post, I’ve wanted to look in to some of the research that was mentioned at StackOverflow DevDays in Toronto, but have been unable to find what I’ve been looking for.

So I created an account on Twitter and asked Joel for his citation. Fittingly, this goes right along with what Greg Wilson was preaching, and I hope that it was just a coincidence, but I do give him credit for re-energizing me and everyone else in the room.

My goal is to look at a study that Joel mentioned in his opening keynote. He brought up a study that was conducted in a California grocery store where shoppers were presented with either 6 or 24 samples of jelly.

# of flavors	% stopped	% purchased
6	40	30
24	60	3

I would like to use the naive Bayes theorem to turn this situation around and ask the question, “Given that a customer was going to purchase, what effect did the number of flavors presented have?”

If you haven’t noticed, I’m really loving this Data Mining class I’m taking.