In 1999, Andrew Hunt created the Rubber Ducking technique – a simple yet innovative debugging concept.
How can a conventional yellow rubber duck, which accompanied him in his day-to-day life, be the answer to his problems as a developer? For Andrew Hunt, it was more than an object. It was the object to which he explained the code when he got stuck. By enunciating all the code, he would always get the answers he was looking for.
The concept of rubber ducking is exactly that: explaining the code, line by line, to slow down thinking and question the process. In this way, it is possible to find the bug and/or solve a problem.
In this article we will review this technique, discuss the benefits of rubber ducking for developers, and spell out all the steps this technique requires.
Table of Contents:
Mostly used by developers, Rubber Ducking is a simple technique for finding and resolving bugs in the written code.
This technique involves reviewing the code and explaining its purpose to an object, plant, animal or even a colleague. The key point of this technique is to go through the code out loud, as if to make something or someone understand what is written.
As the code is explained, the developer gains a new perspective on his own logic of thinking and the decisions he previously took to reach the outlined goal. Also, by listening to oneself, they can understand where the process became more confusing or where it failed.
The Rubber Duck method appeared in 1999 in the book The Pragmatic Programmer written by Andrew Hunt, and the goal was to use a conventional yellow rubber duck as the interlocutor of the message.
The yellow rubber duck, however, is merely figurative. Depending on the situation, it may make more or less sense to explain the code to a human being who will question the logic behind the code and make useful suggestions.
The Rubber Duck technique is simple to use and, most of the time, it has good results in solving bugs.
The biggest difficulty in solving problems in the code may not be solving the issue itself but finding it. And, to find a bug, it is necessary to review code, sometimes without access to any software that does so.
When enunciating the objectives behind the code and explaining the whole process aloud, it is usual to get a better understanding of each of its lines. While the code is being explained, people slow down their thoughts to articulate the discourse. And, by doing so, they will have a more detailed view of each line, enabling them to find the bug faster.
Another reason why Rubber Ducking has benefits has to do with the obligation to explain every line of code in detail without jumping one off.
Besides being easier to find a bug and solve it, the rubber duck technique brings other benefits to developers:
- Allows them to understand what is missing from the code or how to improve it.
- They are constantly reminded of the goals of the code, and therefore help to keep the code in line with them.
- It is possible to find a bug without interrupting the work of a colleague or team, nor the developer is limited by their time.
- It allows them to solve problems without asking third parties for help (unless they choose to do so), reaffirming the skills of whoever wrote the code.
- If the rubber duck is, in fact, a human being, it is possible that this person will ask useful questions and/or present a new perspective on the whole process.
- It allows writing code documentation, both for developers, stakeholders, or anyone else who needs to consult it.
As pointed out in previous sections of this article, the Rubber Ducking technique is easy to use. You just have to take the “rubber duck” to navigate the narrative of the written code.
Although it is (almost) evident how this technique is applied, we leave some tricks that might help build the narrative and explain it to something – or someone.
- Find a rubber duck. It can be a real yellow rubber duck or any other object. If it’s helpful to have another opinion, you can “rubber duck” a real person (even if it’s not a co-worker).
- State the general objectives. Explain the overall plan for achieving these goals, breaking them down into intermediate goals.
- Disclose the steps taken to reach the intermediate goal, explaining each line of code you have written.
- Mention all the errors that were committed during the process and all the corrections made.
- Question decisions made throughout the code.
With these 5 steps and a yellow rubber duck, many developers are able find bugs in the code, as well as the best resolution for them.