De ‘Rubber Duck Debugging’-methode: problemen oplossen door tegen een badeend te praten

Stress, vermoeidheid, externe problemen... elke programmeur moet vechten met fouten of bugs in zijn code en er zijn genoeg redenen waarom debuggen een nachtmerrie kan worden. Er is echter een zeer merkwaardige techniek die teruggaat tot eind jaren '90, en die een rubberen eend (badeend) betreft. Wat is het exacte idee? Dat de programmeur verplicht wordt om de code regel voor regel aan de eend uit te leggen, en via dat deconstructieproces de oplossing te vinden.

De oorsprong: The Pragmatic Programmer

Het verhaal van vandaag gaat terug tot 1999, het jaar waarin Andrew Hunt en David Thomas The Pragmatic Programmer schreven, een boek voor programmeurs dat al snel een universitaire tekst werd. Met behulp van korte verhalen en andere trucs geven Hunt en Thomas de potentiële programmeur tools om het ontwikkelproces te optimaliseren, te beginnen met de noodzaak om een “early adopter” te zijn, zich snel aan te passen, nooit kritisch denken en realisme te verliezen, en als een wildcard te fungeren.

Helaas is het geen erg toegankelijke titel. De nieuwste editie kost niet minder dan 45 euro (tenzij je de digitale versie zoekt), en als ik het me goed herinner is hij nooit in het Spaans vertaald. Maar er zit een klein detail in dat boek dat in recordtijd boven de rest uitstak, en waar veel programmeurs op zweren.

De techniek: praat met een badeend

De sleutel is om een rubberen eend op je bureau te zetten. Wanneer de programmeur een fout niet kan vinden of “vastloopt” op een bepaald punt, wordt de eend een soort luisteraar en passieve student. De ontwikkelaar legt het probleem stap voor stap uit, en via die uitleg vindt hij de oplossing. Dit is vrij gebruikelijk onder collega's (of programmeurs die tegen hun huisdieren praten), maar de eend heeft twee belangrijke voordelen: hij onderbreekt niet, en zorgt ervoor dat we niemand anders lastigvallen.

Het meest waardevolle is dat het de programmeur dwingt om vanaf het begin te beginnen, en terwijl hij vordert, “heranalyseert” hij de code in zijn hoofd. Die bijgewerkte visualisatie van zijn project geeft vaak genoeg duidelijkheid om het probleem te detecteren, zozeer zelfs dat hij soms maar een of twee details van het probleem hoeft te beschrijven. Het lijkt een grap, maar dat is het niet. Terwijl sommige taken een totale aanpak vereisen, moeten andere op de een of andere manier worden “gedemonteerd”, zelfs als het enige publiek een rubberen eend is.