In software engineering (especially XP) there is a commonly held belief that talking to a rubber duck will improve performance when debugging problematic code.

This technique is referenced in multiple places from well-respected blogs such as Coding Horror (in a post about improving the quality of questions asked on this network, no less!) as well as multiple questions and answers on both the Workplace and Software Engineering stackexchange networks.

I also found a reference in a well-respected book 'The Pragmatic Programmer' (although the book seems to advocate using a nodding human rather than a rubber duck - presumably reflecting the relative absence of ducks in a standard office setting) :

Rubber Ducking

A very simple but particularly useful technique for finding the cause of a problem is simply to explain it to someone else. The other person should look over your shoulder at the screen, and nod his or her head constantly (like a rubber duck bobbing up and down in a bathtub). They do not need to say a word; the simple act of explaining, step by step, what the code is supposed to do often causes the problem to leap off the screen and announce itself.

Why "rubber ducking"? While an undergraduate at Imperial College in London, Dave did a lot of work with a research assistant named Greg Pugh, one of the best developers Dave has known. For several months Greg carried around a small yellow rubber duck, which he'd place on his terminal while coding. It was a while before Dave had the courage to ask....

Multiple sources suggest plausible mechanism of action for the effect of explining code to a duck. Here is 'The Pragmatic Programmer' again:

It sounds simple, but in explaining the problem to another person you must explicitly state things that you may take for granted when going through the code yourself. By having to verbalize some of these assumptions, you may suddenly gain new insight into the problem.

and I also found a blog post about the underlying psychology of the technique.

I have been unable to find any academic or industry body studies proving the efficacy of talking to a rubber duck.

I don't think it is unreasonable to expect studies on this to have been carried out because similar, highly referenced, studies(pdf link) exist which show that pairing between real (i.e., non-rubber) humans does improve programmer performance .

In summary this seems to be a widely held belief advocated by several strong voices in the community, and while there is a rational sounding basis for the mechanism of action and there seems to be a lot of anecdotal evidence, there doesn't seem to be any empirical studies proving this effect real.

My questions:

1. Does any empirical evidence exist proving that talking to a rubber duck improves programmer performance when debugging?
2. How large, if any, is the effect? Is it comparable to pair programming with a human?

Edit: I believe my question is different to this question about pendulums because my question is not about quackery. Also because:

1. The answer to the pendulum question is mostly just explaining a plausible mechanism of action but in my question I do not deny there is a plausible mechanism of action for the duck. I am specifically looking for answers with empirical evidence about the use of ducks in the domain of software development. I want to know how large the effect of consulting a duck is. (I have updated the list of questions above to reflect this). While there are academic studies referenced from the pendulum answer they relate to ideometrics (the proposed mechanism of action of the pendulum, but not the duck) so don't constitute an answer to my question.
2. The answer to the pendulum question carefully limits the scope to questions which the pendulum can answer to questions which the asker already knows. The answer says questions like "Will he ask me to marry him?" are out of scope for a pendulum but similar questions may be useful in a pair programming or debugging scenario by prompting the programmer asking questions to which the they doesn't have the answer, to test that possibility, and to help them uncover new information. (E.g., "And so, Mrs Duck, this variable should be set to true when we enter this method...I'll just test that quickly to verify....Aha, it is false!").

In case anyone I did not have a rubber duck available but I did consult a plush parrot, which can be seen photographed below (left), before posting this question but they were regrettably unfamiliar with the literature on this topic.