The duckling method in debugging is a common humorous term for a practice in which a person explains aloud a difficult problem that has driven them into a dead end. Often, simply translating one’s own difficulties into words leads to an unexpected insight that clears the way forward. An inanimate object, such as a rubber duckling, can also act as an interlocutor. Hence the name.
Rubber ducklings are great, of course, but a living person can give even more. In this article, I’m going to share three of my favorite questions that I usually ask when a colleague comes to me feeling like they’re stuck trying to fix a bug. These questions work even if you don’t have any special knowledge in the field to which a particular problem relates. Master them, and you’ll quickly build a reputation as someone to talk to when you’re stuck. And that’s a great reputation!
First question: How did you start studying the problem?
In the process of thinking about a problem, our attention shifts from one thing to another, and then to a third. We begin to think in a certain direction, and forget about other available directions. We get caught up in the details and forget to get back to the big picture. It is very easy to lose objectivity here.
The question “How did you start studying the problem?” gives good results, because the fact that your colleague will begin to remember the entire path traveled, from the first observations to the present moment, can help him to regain the objectivity lost in the process. And the proposed wording saves you from having to openly assume that the other person may have a one-sided view of the matter, which could push them into a defensive position.
Even if your colleague is quite objective in his research, it will still be useful for you to listen to a retelling of the work he has done so that you can ask better questions and help him organize his thoughts.
Second question: What observations did you make?
When fixing bugs in complex cases, it’s easy to lose sight of what you already know. As you progress in your work, you notice a lot of different things – small and large, interesting and boring, important and unimportant. It is simply impossible to keep them all in your head.
If a person is stuck, it is often helpful to review all of their observations. Not theories, not complexities, not actions, but directly observable facts.
It’s worth putting all the facts together for a few different reasons:
- Perhaps a person is considering a hypothesis that contradicts some fact that he has previously established but subsequently forgotten. In this case, he will be able to safely abandon this hypothesis.
- The juxtaposition of the two facts may lead to a new assumption that has not occurred to a person before, because he has not kept both in mind at the same time.
- Listing observations may suggest something that has not yet been studied.
While a colleague is listing the observations, write them down in a numbered list. If possible, ask follow-up questions. For example, “Does X always happen in parallel with Y, or only in some cases?” or “What’s the difference from the standard behavior?”
Question Three: Suppose your hypothesis is wrong, how can you prove it?
This is my all-time favorite question.
One of the most common reasons people get stumped when troubleshooting bugs is tunnel vision. They get hung up on one version of the source of the problem and can’t think about anything else.
Asking, “Suppose your hypothesis is wrong, how can you prove it?” leads them off the beaten path. Instead of straining their brains to prove their point, they are forced to think about other possibilities. This question can lead to several different outcomes, but in any of them, your colleague will be closer to the goal:
- You’ll find a way to prove a hypothesis false, and you’ll do it successfully. It is possible that this will spoil your colleague’s mood for a few hours, but when he returns to the problem again, he will begin to move much faster.
- You’ll find a way to prove a hypothesis false, but it won’t work. In this way, the hypothesis will be strengthened, and it will become clear what the next step should be: to distinguish several within it versions and try to refute them now.
- You won’t be able to come up with a way to test a hypothesis for truth. This means that it can probably be considered a hypothesis at all, since it does not possess Refutability. This means that it needs to be replaced by another hypothesis. It may seem that this is a regression, but in fact, this is the only way to continue moving forward.
Putting it all together
If you look under the hood, these three questions are just different ways of applying the hypothetico-deductive method, which I have already written about in my other articles (Troubleshoot bugs in a distributed team while maintaining common context and Do you know who’s smart? Damn doctors, that’s who). I don’t know of a better way to consistently get results when fixing bugs despite the complexity.
If you’re wondering how to apply these techniques to your career or organization, then I’m here to help. Email me.
———-
Acknowledgement and Usage Notice
The editorial team at TechBurst Magazine acknowledges the invaluable contribution of Productivity Inside the author of the original article that forms the foundation of our publication. We sincerely appreciate the author’s work. All images in this publication are sourced directly from the original article, where a reference to the author’s profile is provided as well. This publication respects the author’s rights and enhances the visibility of their original work. If there are any concerns or the author wishes to discuss this matter further, we welcome an open dialogue to address potential issues and find an amicable resolution. Feel free to contact us through the ‘Contact Us’ section; the link is available in the website footer.