Nel mondo agile tipicamente la persona che scrive è chiamata driver mentre l’altra navigator. A me piace chiamarli rispettivamente tattico e strategico. Trovo che questi termini descrivano meglio il senso del ruolo proprio di ogni elemento della coppia: la strategia è il coordinamento di certe azioni mirando ad un obiettivo più o meno lontano, tattica è l’insieme di mezzi concreti utilizzato per raggiungere il singolo obiettivo intermedio. Quindi: il programmatore tattico scrive il codice, decide come renderlo elegante, leggibile, efficiente e decide, inoltre, come impiegare gli idiomi tipici del linguaggio per risolvere problemi tattici già incontrati; il programmatore strategico invece assiste questo processo pensando un passo più avanti, a come la classe che si sta scrivendo insieme si dovrà interfacciare alle altre preesistemti e alle altre da scrivere ancora, a quali classi si dovranno ancora scrivere, a quali test automatici saranno utili e, fondamentale, a quali design pattern sarà bene impiegare per risolvere problemi strategici già incontrati.

La critica che più frequentemente proviene da chi non ha mai provato questa tecnica davvero appieno – perché chi invece l’ha attuata con sincera dedizione non la critica mai! – è quella dettata dalla pura intuitività: due persone, lavorando contemporaneamente allo stesso compito, non risolvono la metà dei problemi nello stesso tempo? No, vediamo perché.

Se mi permettete di vedere per un momento la coppia di programmatori come un unico essere programmante, il punto fondamentale del pair programming può essere espresso non tanto nel tentativo di raddoppiare i picchi di intelligenza del programmatore che lavora da solo, quanto nel dimezzarne i picchi di idiozia. Con tutto il dovuto rispetto per tutti i programmatori nel mondo, a chi non è mai capitato di incappare in vicoli ciechi per ore, impegnati in tecnicismi di sterile produttività, in perversi gold-plating alla ricerca del Graal della perfezione del codice che non avrebbero mai più avuto riconoscimento in termini sia di gloria sia di denaro? Oppure più semplicemente a chi non è mai capitato di non vedere una soluzione a portata di mano per semplice distrazione o stanchezza? Programmare in coppia riduce il rischio che queste situazioni si ripropongano se non estremamente di rado.

Questa solidità si ripercuote in un miglioramento della qualità del codice scritto, sia a livello locale sia a livello globale, di architettura. Tale miglioramento a sua volta abbassa il tempo speso nel debugging, recuperando molto – se non la totalità – del tempo perso per l’assegnamento di due persone allo stesso task. La pratica del test-driven programming – di cui parleremo – entra in forte risonanza con la pratica del pair programming portando i team XP molto vicini all’ideale abolizione del debugging.

Abolire il debugging significa produrre di più. Non dimentichiamolo mai: fare debugging non è mai produttivo. Il debugging è sempre solo un costo.

Poco sopra ho scritto che il tempo recuperato con l’incremento di qualità della scrittura del codice non è detto che compensi completamente il rallentamento dovuto alla duplicazione dell’assegnazione sviluppatori-task. Alla resa dei conti ci interessa solo sapere se una pratica ci permetta di risparmiare tempo in assoluto e in pratica e non solo in teoria o in presenza di fortunate condizioni coincidenti. Perché allora insistiamo nell’adottare una tecnica che forse, pur se poco, qualcosa ci fa perdere in termini di tempo? La risposta è semplice: per ottenere predittibilità .

La verità è che un processo industriale sano ottiene pochi vantaggi dalla possibilità di essere rapidissimo se non può integrarsi con stime attendibili – seppur non necessariamente esatte. Il debugging è un’attività che, oltre a non essere produttiva, è completamente imprevedibile. Pertanto, ammesso e non concesso che il pair programming comporti un effettivo rallentamento dello sviluppo, possiamo tranquillamente stabilire che il costo di un rallentamento sufficientemente piccolo può essere accettato se in cambio si ottiene la possibilità di ridurre l’impatto del debugging nella pianificazione e quindi di fare dei piani di precisione maggiore.

Concludendo, il pair programming è una pratica che offre un intero ventaglio di vantaggi nell’attuazione di una metodologia agile per lo sviluppo software. Tra questi abbiamo visto che troviamo anche la possibilità di migliorare il planning dei nostri progetti con buona pace di manager, sviluppatori e clienti.

A presto con il prossimo articolo! Ciao!