DAD, Non-solo Programming

Devo ammetterlo, prima di approfondire con DAD la questione del non-solo Programming, la mia associazione era di 1:1 con il pair-programming di XP, ovvero la programmazione congiunta da parte di due sviluppatori davanti allo stesso computer.
La pratica non ha mai riscosso la mia particolare simpatia, sia perché non sempre è facile trovare il collega con cui sviluppare congiuntamente, sia perché i costi della relativa applicazione portano facilmente fuori budget il progetto.

In realtà bisogna riconoscere che il non-solo programming ha una sfumatura decisamente più raffinata, che non minimizza la questione alla "sola" scrittura di codice, ma la estende ad ogni aspetto del progetto, compresi quelli più avanzati.

nonsolo programming

Si pensi al Design: discutere con uno o più colleghi di soluzioni che abbraccino domini complessi è sicuramente più produttivo e costruttivo rispetto ad affrontare in solitario la questione. Inoltre questa pratica favorisce in modo naturale la condivisione del know-how, riducendo la necessità di documentazione. Anche la concentrazione e la motivazione trae beneficio dal lavorare "in coppia", visto che si è spronati a dare il massimo durante la propria attività.

Nel caso specifico della scrittura del codice si ottiene un miglioramento qualitativo generale di quanto realizzato, diminuendo la necessità di review dello stesso ed evitando di focalizzarsi su elementi di scarsa efficacia. Un caso specifico in cui è buona norma applicare il non-solo development è quello che vede coinvolti un senior ed uno junior developer, al fine di trasferire "sul campo" know-how e nozioni specifiche del dominio.

Un ulteriore ambito in cui il non-solo development dà grandi benefici è l'avvicendamento dei membri del team o il trasferimento delle attività di manutenzione a DevOps terzi: si abbattono così i tempi necessari al passaggio di consegne e si evitano di creare lacune che poi sono difficili da colmare, anche in presenza di documentazione aggiornata realizzata con la tecnica del Document Continuously.
Fattore da non sottovalutare, infatti, è l'abbattimento della dipendenza dal singolo sviluppatore che, così, smette (o almeno limita) di essere un "single-point-of-failure" perché il know-how specifico è condiviso con almeno un ulteriore membro del Team. In tal modo se un dev è assente, ad esempio per malattia, un altro membro del team, se necessario, può sopperire alla sua mancanza. Chiaramente ciò implica che quest'ultimo debba rimodulare le proprie priorità affinchè non abbia un over-head di lavoro che porta ad abbattere la propria efficienza.

In sintesi il non-solo programming è una pratica che consolida il Team in gran parte dei suoi aspetti, permettendo di ottenere una soluzione di migliore qualità ed eliminare rischi dovuti al fatto che solo un membro di esso sia in grado di operare su una parte del sistema.