Pair programming 1

Tanto tempo fà, precisamente nel 1998, ho avuto la mia prima esperienza di programmazione in coppia.

Cosa significa? In buona sostanza si tratta di scrivere il codice di un’applicazione (o parti di essa) insieme ad un’altra persona, in coppia appunto, davanti allo stesso videoterminale.

Ho coniato io questa definizione perché non ho trovato nessuno che sapesse dargli un nome specifico e perché rende bene l’idea. Grazie al commento di Lor ho trovato la definizione giusta “Pair programming”.

Il primo software che ho pubblicato nella rete con questa tecnica, insieme a Lorenzo Colitti, è CNet-Guard.

Lo scopo del suddetto software era di ripristinare il servizio della BBS che gestivamo insieme a quei tempi (Antanisoft BBS) in caso di crash di uno o più terminali virtuali; un vero e proprio watchdog. Vien da sé che un software del genere non può rischiare di “inchiodarsi” perciò quello fu il motto con cui lo progettammo, ovvero “Questo software non si può inchiodare!“.

Al tempo io avevo 24 anni e Lorenzo 22.

Cosa c’è di speciale nel programmare in questo modo? Sicuramente la domanda vi è venuta alla 3° riga di questo post… ora tento di spiegarvelo secondo la mia esperienza benché sia già spiegato molto bene e in modo più esteso nell’articolo di wikipedia.

• E’ più divertente: guardare da vicino ciò che l’altro scrive o essere scrutati, discutere in tempo reale sulle scelte fatte, sull’eleganza del codice appena scritto, sulle prestazioni, e sull’ottimizzazione delle risorse è un ottimo modo per non abbrutirsi davanti al computer, da soli, per decine di ore.
• Migliora la qualità del codice: essere costantemente sotto controllo produce un effetto continuo di “ansia da prestazione” per lo scrivente (nell’accezione più positiva del concetto) e “supporto proattivo” da parte di chi partecipa senza scrivere. Si sarà più vigili e attenti a ciò che si fa o che fa l’altro. Potenziali bug, inefficienze, storture, problemi di sicurezza, ecc. saranno minimizzati.
• Effetto “Continuous coaching”: lavorando insieme di solito si impara sempre qualcosa. Farlo in tandem è un modo molto efficace di apprendimento che supera quelli per esempi, esercizi, corsi, ecc. Stai continuamente sul “pezzo” e devi quagliare, non ci sono fronzoli, teorie o formule che forse non userai. E’ tutta polpa.
• Nel caso di codice particolarmente complesso, riduce i tempi di sviluppo: si sà che due cervelli ragionano meglio di uno. Questo è un caso esemplare. Il lato negativo è che in un’azienda, impegnare due persone al posto di una è più costoso; questo però è forse il caso dove questo assunto non è più vero del tutto.

Questi assunti hanno però bisogno di un terreno fertile per concretizzarsi, altrimenti il tandem può rivelarsi controproducente, ovvero:

• i due programmatori devono avere un livello di esperienza simile e conoscere entrambi il linguaggio di programmazione adottato, altrimenti si rischia che faccia tutto uno solo, vanificando completamente la collaborazione;
• devono essere in grado di comunicare agevolmente (nella stessa lingua) pena un notevole rallentamento dell’operatività a causa dei continui confronti di idee;
• devono alternarsi al videoterminale cosicché il programmatore che supervisiona non possa concedersi troppe distrazioni perché poi toccherà a lui;
• devono essere in buona sintonia, allo stesso modo di una cantante con il musicista o due giocatori di Scopone Scientifico;
• devono condividere la filosofia e i buoni principi di programmazione;
• devono essere persone equilibrate, nel senso di avere l’empatia necessaria per condurre un’attività del genere senza tendere troppo a prevalere o sottomettersi.

Negli ultimi 15 anni mi è successo varie volte di intraprendere attività in coppia (ad esempio con Fabrizio Catalucci, Fabio Ambrosanio e altri), non solo per la scrittura di codice ma anche per attività sistemistiche, di sicurezza, ecc. Con le persone giuste, il problema da risolvere adatto e i mezzi adeguati, il pair programming funziona, garantito.

Sconsiglio la programmazione in coppia quando il lavoro da svolgere è semplice. Porta quasi sicuramente ad una perdita di tempo.

Per approfondire sull’argomento vi rimando ad un notevole articolo sul tema (solo in inglese).