What is Rubber Duck Debugging and does it work?

Posted on 20 February 2019 by Bradley Taylor

As programmers, problem solving is a big part of the software development process. Frequently these problems are complicated enough that we need help, and in these moments it is tempting to turn to our co-workers for assistance. But there’s a better alternative: Rubber Duck Debugging.

The whole team can benefit from Rubber Duck Debugging

Think back to the last time you had to talk through a problem with someone else. I expect you picked a partner, slowed down, and really started to think about what you wanted to say. You probably had to step back and give some context about what you were actually trying to solve. Then, when describing the problem, you probably realised the solution as well, without your partner having to say a word!

If your partner didn’t need to do anything but listen, did they really need to be involved? It turns out they didn’t. If you’d picked an inanimate object, such as a rubber duck instead, you could have solved your problem without disrupting your team. And best of all, a rubber duck is available whenever and wherever you are.

Teach your duck!

So what’s going on here? Well, it’s similar to what happens when you teach. People who teach a subject often find they come to insights they wouldn’t have had before they started. By teaching you think about things in different ways. You see connections between concepts that you didn’t notice before.

The history of Rubber Duck Debugging

Rubber Duck Debugging isn’t a new idea. First coined in the 1999 book The Pragmatic Programmer, it has frequently proven itself as a useful tool in the software development process. You may also have seen rubber duck debugging referred to as simply “Rubber Ducking”, especially if you work outside the software industry, but still do a lot of problem solving.

It’s not about the duck

The rubber duck may, ironically, be the least important part of the rubber ducking debugging technique. You don’t need a rubber duck to get started (although what developer wouldn’t want one of these rubber ducks on their desk?).

If you don’t have a rubber duck, try one of these approaches instead:

  • Any inanimate object will work equally well. A similar method is the “dumb rock” technique, where you talk to any rock you can find.
  • If you’re in a quiet office and don’t feel comfortable talking to rubber toys, then try writing down your problem instead. Your hand won’t be able to go as fast as your thoughts, and so you will be forced to focus on the important parts of your issue.
  • Move away from your desk and describe the problem to yourself. A short walk outside could help you focus on what the problem is. By moving away from the code you will have to think about the issue in a more generic way, which might lead you towards the correct solution.

Try it yourself!

Next time you have an issue you just can’t solve, step away from the code, explain your issue (just like you would if you were explaining the problem to a colleague), and give yourself the time to come to the solution yourself. Most of the time you’ll get to the answer without needing to disturb anybody else. And if not, you’ll have a clearer idea of how to ask your question if you do need to turn to another person for help.