Rubber duck debugging

This is Dave.

He is a valuable and irreplaceable member of the KISS Digital Development Team. He is solely responsible for solving a surprisingly large percentage of code bugs that we encounter. Whilst he has no godlike programming skills he is a patient listener. With his assistance, using the rubber duck debugging method, his reliable and calming presence enables us to assess and overcome hurdles that we might otherwise needlessly sink hours into trying to fix.

No I'm not quackers, the rubber duck method is a serious and incredibly useful way of correcting fowl-ups in code. It's a method of problem solving that involves explaining ‘what the code does’ or ‘is supposed to do’ as simply as possible to any inanimate object that is lying around on your desk. By forcing yourself to look at the problem in front of you in a different way you can uncover bugs that you hadn't previously seen. When dealing with the complexity that can be associated with programming, it’s often too easy to get caught out by the simpler problems. Explaining your issues to someone (even a plastic duck!) who has no expertise in your area often enables you to see the wood through the trees and bring clarity, and often a solution, to an issue that you have been trying to solve.

This method was first described in The Pragmatic Programmer, published in 1999, and is now a well-known and widely used problem solving technique. There are many great stories of software engineers being taught this approach, and from my perspective it has assisted me on so many occasions.

If I find myself staring at a screen of code for too long, unable to troubleshoot an issue, I simply have to look down and Dave is there and ready to help. He’s my reliable friend who never takes a holiday or sick days (not even for bird flu!).

“Dave” I say…

“…” (He never answers back, he simply waits to hear my problem.)

And so I go on to describe the issue I’m faced with, starting with what I’m trying to achieve and what I have done. This ‘taking a step back’ approach can mean it’s only moments before I discover a typo in the code, or uncover some flawed logic that’s resulted in the brick wall I’ve just spent nearly an hour trying to smash through.

Rubber duck debugging helps save time when problems do arise and can often be a great alternative to disturbing co-workers when it’s not necessary. Why not give it a go? Next time you have a perplexing problem to solve, try explaining it to the least embarrassing inanimate object on your desk, whatever fits the bill. But for me I will keep asking Dave the Debugging Duck.