Home >> Articles >> Rubber Duck Debugging

When working on complex code, programers can sometimes become quite frustrated. It almost always happens that there are errors in the program, called bugs, which cause the program to not work as intended and can cause the programmer to pull out their hair in anger, despair, frustration, indignation, etc. Because of the complexity of the code involved in large programs, it's often not obvious why the program isn't working correctly, and sometimes difficult to even know exactly where to start to find the error. In addition, sometimes the programmer is so deep into the code and some much into their programming zone, they can't back out their perspective enough to see what's actually happening in the program execution. What's a hardworking programmer to do when they can't chase down the bug but the problem is right there in front of their face?

There is a well known technique for getting un-stuck and on-track to finding the error.  What programmers sometimes do is find another programmer and bring them over to their computer.  The programmer with the problem will start describing the problem to the other programmer and will explain to the other programmer step-by-step what the code is doing.  As the troubled programmer goes through their explaination, there is typically an "AH HA!" moment when they realize that the code is not actually doing what they're explaining.  The troubled programmer will then get back to work and let their co-worker get back to their own work.

That technique works well, but it involves disturbing another person and exposing yourself to potential embarassment due to the telling your peer about your flawed code.  The good news is that it turns out another programmer isn't actually required.  In fact, another person is not actually required.  In fact, you can use a rubber duck who may only have the barest inkling of what programming is.  You can even work with that one rubber duck who, well, gives you that less-than-bright look when you talk to them.

Here's an example rubber duck debugging session in which our hero, Clarice, is working with her rubber duck debugging buddy, D'Artagnion, to sort out a particularly insidious bug:
Clarice:  So at this point the rubber duck object instance is created and its mass and volume are set.
D'Artagnion: ....
Clarice:  And as you can see next, the buoyancy calculation routine is called because the volume has been updated.
D'Artagnion: ....
Clarice:  And now that the   OH!  AH HA!  I see it!  I can't believe I calculated the buoyancy using non-thread-safe data!  Thank you D'Artagnion!!!!
D'Artagnion: SQUEAK!

And another bug goes down thanks to a very patient rubber ducky friend. Who could ask for a better programming companion?

(No, really, we didn't make this up!)