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. The parrot (left) which was consulted.

  • 27
    I can confirm from personal experience that explaning my problem to the "Ask a question" box on stackoverflow.com very often enables me to see a dumb mistake I'd made that had eluded me for hours... I assume explaining it to a rubber duck could have a similar effect! – user568458 Mar 22 '17 at 17:37
  • 3
    @JasonR The questions aren't even remotely similar. If you think that the "rubber duck" technique is fundamentally the same as the "pendulum" technique, explain why (with evidence) in an answer, that then links to / quotes from that other answer. Otherwise, your reasoning is hidden and unaccountable in the close vote mechanism. – user568458 Mar 22 '17 at 17:39
  • 10
    "my question is not about quackery" -- I see what you did there... – Gareth McCaughan Mar 22 '17 at 18:25
  • 5
    If you find any, I'd love to see how the academics define programming efficiency! I'm more skeptical of a good universal definition of programming efficiency than I am of the rubber duck! – Cort Ammon Mar 23 '17 at 0:53
  • 10
    Its not about the rubber duck. Its about being forced to explain things very clearly. If you stare at the code you have implicit assumptions in your head. If you explain it to someone else (or pretend to explain it to someone else), you need to spell out all these assumptions and be precise about what you think the code does. This often reveals that you either don't actually know what some code does or that your asumptions are wrong, and thus enable you to find the bug much easier. Asking on SO is the same process and often phrasing the question makes it clear where the problem is. So its true – Polygnome Mar 23 '17 at 16:46

You're not going to find studies that do something like compare the effectiveness of a rubber duck vs a stuffed parrot specifically for programmers working on debugging tasks, nor can we really measure the size of the effect, but your main question can be answered if we approach it at a slightly higher level: does talking through a problem aloud aid in problem solving?

To which the answer is clearly yes.

Enhance Metacognition and Problem-Solving by Talking Out Loud to Yourself

In recent research on TAPPS, reported in the University of Arkansas publication Research Foundations, Spring 2011, the author noted that the increased speed and effectiveness of partner problem-solving has little to do with the monitor and much to do with the problem solver’s own behavior; thinking aloud or TA. The constant verbalization of their thoughts out loud encouraged the problem solvers to continuously correct faulty steps in logic. The causal mechanism of success was the problem-solver’s metacognition.

TAPPS is "Talking Aloud Partner Problem-Solving", where one of the partners is the "active" partner, thinking aloud through a problem, the other is simply a "monitor" or "listener", playing a role only slightly more interactive than our programmer's rubber duck.

There is lots of scholarly research out there about TAPPS.

Another article summarizing a different research study: Thinking out loud helps solve problems

Professor Jose Luis Villegas Castellanos, of the University of the Andes, Venezuela, said that discussing problems was a smart way to learn.

"Those students who think aloud while solving a mathematical problem can solve it faster and have more possibilities of finding the right solution that those who do not do it," he said.

The study, led of the University of Granada, Spain, focussed on final year university maths students, who were recorded while trying to answer complex maths problems.

Those who detailed their thinking process aloud had more chance of answering the same question correctly as those who did not talk about their problem solving plan, the researchers found.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .