Eine Autorin dieser Kolumne kannte eine Produktmanagerin, die gerne bei den Softwareentwicklern im Büro aufschlug und, an den Türrahmen gelehnt, ein Problem beschrieb. Die Entwickler guckten aufmerksam, hörten zu, machten sich Gedanken über hilfreiche Lösungsvorschläge. Doch zum Antworten kamen sie nie. Sobald die Produktmanagerin ihre Ausführungen beendet hatte, sagte sie: „Ach, ich weiß jetzt, wie ich das mache. Danke!“ Und verschwand.
Die andere Person muss nur zuhören und nicken. In überraschend vielen Fällen findet man die Lösung oder zumindest die Ursache des Problems dann selber.
Die Methode, die hier sehr erfolgreich angewendet wurde, ist in der Softwareentwicklung unter dem Namen Rubber Duck Debugging bekannt. Um einem hartnäckigen Bug auf die Schliche zu kommen, wird dazu geraten, sich jemanden dazuzuholen, der den Code nicht kennt. Dieser Person erklärt man, was der Code tun soll, was er tatsächlich tut oder eben nicht. Die andere Person muss nur zuhören und nicken. Oder einfach nur aufmerksam gucken. In überraschend vielen Fällen findet man die Lösung oder zumindest die Ursache des Problems dann selber.
„Also, pass auf“, sagt man, „hier ist das Stück Code, in dem der Fehler stecken muss. Es ist total kompliziert, weil ich damit ein total kompliziertes Problem bearbeite. Und einfacher geht es nicht, weil … ähm … oh, warte.“ Dann fällt einem ein, dass man sich die komplizierte Lösung letzte Woche für einen bestimmten Sonderfall ausgedacht hat. Den hat man umgehend wieder vergessen, und jetzt ist man gerade dabei, die Normalfälle mühevoll so hinzubiegen, dass sie dem Sonderfall ähneln. Wahrscheinlich stellt man dann auch noch fest, dass der Sonderfall gar keiner ist und die simple Lösung von Anfang an genügt hätte. Man kann dem stummen Helfer dann als Dank einen Keks geben und ihn wieder wegschicken. Man weiß ja jetzt, wie man weitermachen muss.
Daher braucht man auch gar keinen richtigen Menschen. Es reicht eine Gummiente, die neben dem Monitor sitzt, während man ihr sein Leid klagt. Daher der Fachbegriff.
Man kennt das Prinzip ja aus vielen Lebenslagen, aber die speziellen Sorgen des Programmierers löst es besonders gut. Die Grundannahme: Bei der Fehlersuche befindet man sich in einem Geisteszustand, in dem man vor lauter Detailwissen nicht mehr in der Lage ist, das Problem strukturiert zu durchdenken. Indem wir uns zwingen, die Funktionsweise des Codes ganz von vorne zu erklären, hinterfragen wir Präsuppositionen, deren Sinn und Zweck wir bis dahin ganz betriebsblind als gottgegeben hingenommen haben. Die uns aber, sobald wir sie laut aussprechen, nicht mehr so selbstverständlich erscheinen. Und eventuell der ganze Ursprung des Übels sind.
Auf der Frage-und-Antwort-Plattform Stack Overflow, auf der es für fast jedes denkbare Programmierproblem eine Antwort gibt, gelten ähnliche Regeln wie beim Rubber Duck Debugging. Wer hier beim Fragestellen schludert, Informationen beizulegen vergisst oder wichtige Voraussetzungen verschweigt, wird gerne von den potenziellen Wissensträgern abgesnobbt. Wer sich aber schon beim Aufschreiben der Frage Mühe gibt, wird nicht nur wahrscheinlicher eine Antwort erhalten. Schon das verständliche Formulieren und Anfertigen eines minimalen Codebeispiels führt oft direkt zur Lösung. Sogar ohne, dass man es überhaupt abgeschickt hätte.
Wie gesagt: Fortgeschrittene können Rubber Duck Debugging auch auf andere Lebensbereiche anwenden. So kann man seine Idee für ein Startup auch dem Hund beim Abendspaziergang erörtern. Oder man klebt dem Obst Augen aus Papier auf und erzählt der Orange von den Problemen, die sich bei der Integration von System A in System B ergeben. Und: Die Tätigkeit als Rubber Ducky ist ja auch für Menschen, die sie ausüben, dankbar. Man macht sich nützlich, wird gelobt, muss aber nichts tun, außer anwesend zu sein und interessiert zu gucken. Gäbe es den Ausbildungsberuf Professional Rubber Ducky, man müsste ernsthaft über eine Umschulung nachdenken.
Kathrin Passig und Anne Schüßler schreiben leidenschaftlich Blogs, Tweets und Code. In WIRED geben sie regelmäßig Überlebenstipps für Nachwuchsprogrammierer.
