La papera di gomma: spiegare il codice a chi non risponde
Un assistente di ricerca spiegava il codice, riga per riga, a una papera di gomma. Il più piccolo rito di controllo di chi costruisce.
Nell'ottobre del 1999 Andrew Hunt e David Thomas pubblicarono con Addison-Wesley The Pragmatic Programmer, un libro che non propone una teoria ma una raccolta di consigli per chi scrive software. Dentro c'è una storia minuscola. Un assistente di ricerca, Greg Pugh, portava con sé una papera di gomma. Quando un problema non si lasciava trovare, la metteva davanti a sé e le spiegava il codice, passo dopo passo.
La papera non doveva dire nulla. Secondo gli autori, il semplice atto di spiegare che cosa il codice dovrebbe fare spesso fa saltare il problema fuori dallo schermo, come se si annunciasse da solo. Da quella storia viene un nome che oggi si insegna nei corsi di informatica: rubber duck debugging, il debug con la papera di gomma.
Un ascoltatore che non interrompe
Il meccanismo non ha niente di magico. Chi scrive codice tiene in testa due programmi: quello che crede di aver scritto e quello che ha scritto davvero. Finché resta in silenzio, il primo copre il secondo. Quando deve dirlo ad alta voce, una riga alla volta, in lingua naturale, è costretto a confrontarli. A quel punto la differenza si vede.
Un collega servirebbe allo stesso scopo, ma un collega interrompe, intuisce, completa le frasi al posto tuo. È gentile, ed è proprio questo il limite: ti risparmia il pezzo di spiegazione in cui si nascondeva l'errore. La papera non intuisce niente e va accompagnata fino in fondo. Per questo funziona meglio che pensare ad alta voce senza pubblico: c'è qualcuno davanti, anche se di plastica, e a qualcuno si spiega per intero.
Le varianti sono note. C'è chi usa un orsetto di peluche, chi un animale di casa; S. J. Baker ha scritto perfino del contributo di un cane di cartone all'affidabilità del software. L'oggetto cambia, la regola resta: parlare a una presenza che non ti aiuterà.
Il rito più piccolo del laboratorio
Mi interessa perché è un controllo, non un trucco. Nel sistema operativo di chi costruisce ci sono controlli che girano da soli: test, audit, routine che ogni mattina verificano che tutto sia ancora al suo posto. E ci sono controlli che non si possono automatizzare, perché la macchina da verificare è la propria comprensione. La papera appartiene a questa seconda famiglia. Non trova l'errore: mette chi scrive nella posizione in cui l'errore diventa visibile.
Vale oltre il codice. Un capitolo che non regge, una procedura che sembra chiara, un messaggio che si crede ovvio: letti ad alta voce a qualcuno che non può fingere di aver capito, mostrano le loro giunture. Scrivere bene è anche questo, accettare che la frase di cui siamo più sicuri sia la prima da spiegare.
Il primo aprile 2018 Stack Overflow ne fece uno scherzo, Quack Overflow: una papera nell'angolo dello schermo ascoltava i problemi degli utenti, fingeva di scrivere una soluzione e rispondeva con un verso. Era una battuta, ma diceva il vero. La risposta non era mai stata nella papera.
Un giocattolo da vasca da bagno, cavo e muto, è diventato così una piccola reliquia di laboratorio. Non per quello che sa, ma per quello che costringe a dire. È la stessa idea che sta sotto Il sistema operativo del builder: una struttura non lavora al posto di chi costruisce, rende visibile ciò che altrimenti resterebbe nascosto.
Fonti: Andrew Hunt e David Thomas, The Pragmatic Programmer, Addison-Wesley, 1999; The Pragmatic Programmer e Rubber duck debugging, Wikipedia (consultate il 20 ottobre 2026).
> ln -s ./linked-nodes
- [PARTE DI] Sistema Operativo Builder
- [CORRELATO] Il sistema operativo del builder
- [CITATO DA] La falena del Mark II: il registro che corresse la memoria
- [CITATO DA] L'assegno da 2,56 dollari: Donald Knuth e il premio per chi trova l'errore