As a developer, I think all of us can remember a time where we have spent all day trying to resolve a particular bug, only to figure out the solution ourselves as soon as we begin to explain the problem to a colleague. Well it turns our you are not alone. Rubber duck debugging is a term used to define the method of debugging where by explaining your code actually uncovers the problem.
Why does this work?
By forcing yourself to sit down and explain your code, you begin to look at your code in a completely different light. Typically, you read and reread all of your code trying to find a problem, however by actually having to explain it, you have to take it to that extra level of understanding which often enough to uncover the originating cause of the bug.
Another way to look at it is that you truly don’t understand something until you can explain it to someone else. By explaining your problem out loud, even to someone that doesn’t understand you, the act of thinking about something to the point of being able to easily explain it will allow you to uncover the underlying cause of your problem.
Where did the name “Rubber duck debugging” come from?
A story told to me by one of my old lecturers was that term ‘rubber duck debugging came about because a famous unnamed programmer would keep a rubber duck on his desk, and every time he came across a problem, he would explain all of his code, line-by-line, to his duck. The idea being that by explaining the problem to someone, even an inanimate object like a rubber duck, he would see the problem through a different lens and often uncover the cause.
For more on wikipedia: http://en.wikipedia.org/wiki/Rubber_duck_debugging