Rubber ducks: a journey from water splashing to code debugging

I was telling you in the previous post about the XY problem, when someone asks for what they think is the solution to the problem, instead of the actual problem. Well, besides the 5 whys technique, when you are the helper or asking smart questions when you need help, there is one other thing that you can do and it just might help you more than you think.

Rubber ducks are not only good for taking baths, they can also help you with your problem solving or your programming. Of course, you don’t have to use a rubber duck – if you think your teddy bear can ace a duck in a programming contest, go ahead and use the teddy bear.

Don’t think that your duck or bear will magically start spilling out programming advice – they have more of a coaching position – they do not tell you what to do and you will have to find the solution yourself, but they will help and they help by just being the great listeners inanimate objects are.

I will bet this happened to you before: someone comes with a problem and they ask for your help. And as they start telling you about their problem, they will have an “aha” moment and figure out how to solve the problem by themselves.

Taken from “The Pragmatic Programmer” by Andrew Hunt and David Thomas, this approach works because one of the best ways to understand a problem is to try to explain it to someone. Especially when that someone is a rubber duck – you will try harder to explain in detail than you would explaining it to a fellow programmer.

At the end, I will also provide the easy steps one should take in order to successfully employ rubber duck debugging or programming (taken from here) they were just too good not to mention:

Step 1) Beg, borrow, steal, buy, fabricate or otherwise obtain a rubber duck (bathtub variety)

Step 2) Place rubber duck on desk and inform it you are just going to go over some code with it, if that’s all right.

Step 3) Explain to the duck what your code is supposed to do, and then go into detail and explain your code line by line

Step 4) At some point you will tell the duck what you are doing next and then realise that that is not in fact what you are actually doing. The duck will sit there serenely, happy in the knowledge that it has helped you on your way.

The XY problem

Ever heard about the XY problem? Well, quoting from a site dedicated to this, “the XY problem is asking about your attempted solution rather than your actual problem. This leads to enormous amounts of wasted time and energy, both on the part of people asking for help, and on the part of those providing help.”

And the XY problem is more common than you might think – I was telling my girlfriend some weeks ago about the XY problem and she went: that is exactly what happened to me today! One of her colleagues asked for her help in finding an internal reference number for an invoice. So my girlfriend pulled a copy of the invoice from one of the systems, using information from the invoice copy she tried to track down that internal reference that was not really used by people in her department in another system and after some time she asked her colleague: but why do you need that internal reference number? So I can retrieve a copy of the invoice, the colleague said. If the colleague had stated from the start what she wanted – the invoice copy – instead of asking about a reference that she thought would help her retrieve the invoice, it would have not wasted unnecessary time for both of them.

And that happened in a finance environment, but it happens even more often in software development. I actually got to hear about the XY problem from our CTO who has had a fair share of XY questions received from the developers.

In my opinion, something that can be used (besides the solutions on the XY problem site) is the 5 whys technique, used in process improvement. Used to determine the root cause of a defect or problem by repeating the question “Why?” several times (you do not have to ask the question exactly 5 times, can be less or more) I think it can also be used here, without even having to ask to many times the why, as when you do when using it in process improvement – it might just take one why to find out the X of the problem instead of the Y.