La «Depurazione della Paperella di Gomma», o come correggere problemi parlando con un giocattolo

Stress, stanchezza, problemi esterni… ogni programmatore deve lottare con errori o bug nel proprio codice, e ci sono fin troppi motivi perché il debugging diventi un incubo. Tuttavia, esiste una tecnica molto curiosa che risale alla fine degli anni '90 e che coinvolge una paperella di gomma. Qual è l'idea esatta? Che il programmatore sia costretto a spiegare al papero una riga alla volta del proprio codice, e attraverso questo processo di scomposizione trovare la soluzione.

La storia di oggi risale al 1999, anno in cui Andrew Hunt e David Thomas scrissero The Pragmatic Programmer, un libro per programmatori che divenne rapidamente testo universitario. Con l'aiuto di racconti brevi e altri trucchi, Hunt e Thomas forniscono al potenziale programmatore strumenti destinati a ottimizzare il proprio processo di sviluppo, a partire dalla necessità di essere un «early adopter», adattarsi in fretta, non perdere mai il pensiero critico né il realismo, e funzionare come una jolly.

Purtroppo, non è un titolo del tutto accessibile. La sua ultima edizione non scende sotto i 45 euro (a meno che non si cerchi la versione digitale), e se la memoria non mi inganna, non è mai stato tradotto in italiano. Ma c'è un piccolo dettaglio in quel libro che si è distinto sopra gli altri in tempi record, e su cui molti programmatori giurano.

Il metodo della paperella di gomma

La chiave è mettere una paperella di gomma sulla scrivania. Quando il programmatore non riesce a trovare un errore o rimane «bloccato» in un certo punto, il papero diventa una sorta di ascoltatore e studente passivo. Lo sviluppatore procede a spiegare il problema passo dopo passo, e attraverso questa stessa spiegazione trova la soluzione. Questo è abbastanza comune tra colleghi e compagni di lavoro (o programmatori che parlano ai propri animali domestici), ma il papero ha due importanti vantaggi: Non interrompe, ed evita di disturbare qualcun altro.

Perché funziona

La cosa più preziosa è che obbliga il programmatore a partire dall'inizio, e avanzando non fa altro che «rianalizzare» il codice nella propria mente. Quella visualizzazione aggiornata del proprio progetto di solito fornisce abbastanza chiarezza da individuare il problema, al punto che a volte basta descrivere uno o due dettagli del problema. Sembra uno scherzo, ma non lo è. Mentre alcune attività richiedono un approccio totale, altre devono essere «smontate» in qualche modo, anche quando l'unico pubblico è una paperella di gomma.