Ho provato diverse volte a programmare in coppia, anche all'interno di un'organizzazione che (brevemente) ha considerato la possibilità di implementarla come un processo obbligatorio per tutti gli ingegneri (puoi immaginare quanto bene sia stata elaborata l'idea). Personalmente, l'ho odiato.
Le ragioni che elencherò di seguito sono solo le mie esperienze soggettive e non posso "misurare" il loro impatto in termini concreti. Ma qui sono tutti uguali:
1 - Avere un 'navigatore' e un 'driver' aiuta solo se il primo è vocale e il secondo ascolterà.
Abbiamo incontrato tutti gli sviluppatori che sono testardi, zelanti per qualche preoccupazione teorica o patologicamente incapaci - psicologicamente - di "buttare via" il vecchio lavoro quando qualcuno suggerisce un problema. E tutti conosciamo individui troppo timidi o diffidenti per sollevare dubbi o suggerire casi angolari.
Quando questi tipi di sviluppatori sono accoppiati, il navigatore assume rapidamente un ruolo passivo e ciò che si ottiene è la programmazione esclusiva con una revisione automatica del codice. Questo è uno spreco di risorse monumentale.
2 - L'associazione impedisce la creatività.
Contrariamente a quanto si pensava in precedenza sul valore del "brainstorming di gruppo", il consenso in questi giorni è che il lavoro di conoscenza creativa richiede indipendenza e autonomia . Quando lavori da solo, puoi rapidamente hackerare insieme un'idea folle per vedere se è effettivamente fattibile. Puoi assemblare senza parole alcuni strani prototipi e, se fallisci, non importa, perché nessuno lo sa .
Confrontalo con l'accoppiamento: quando voglio provare qualche nuovo concetto, devo convincere il mio partner, parlare attraverso l'implementazione, passo dopo passo, e spero che non mi giudichino se fallisce. Questo tipo di ambiente è tossico per la creazione di nuove idee.
3 - Design con il minimo comune denominatore.
Quando una coppia non è in grado di sviluppare nuove idee, come sopra, o quando gli individui non riescono a concordare alcuni principi fondamentali su come dovrebbe essere progettata una caratteristica, ciò che ne risulta è un disegno confuso che tenta di scendere a compromessi e non soddisfa nessuno.
Se abbini uno sviluppatore che costruisce astrazioni di programmazione funzionali meravigliose, eloquenti, verso il cielo con un maniaco delle prestazioni veloce e sporco, il codice che produrranno insieme in genere non sarà né terribilmente elegante né particolarmente veloce.
4 - Mancanza di autonomia e trasparenza violenta.
Trasparenza violenta è una frase che ho preso da una polemica moderatamente famosa (e piuttosto controversa) contro la metodologia Scrum. Descrive il modo in cui alcune organizzazioni infantilizzano gli sviluppatori e li trattano con il sospetto normalmente riservato ai lavoratori non professionisti.
Qualunque cosa tu pensi del "danno" di rendere il lavoro degli sviluppatori completamente trasparente (e potresti non essere d'accordo sul fatto che in realtà è un danno), molte persone apprezzano la loro autonomia e la loro capacità di lavorare da soli, fidati di fare la cosa giusta. È un bisogno psicologico importante e costringere gli sviluppatori ad accoppiarsi (come ho visto accadere in almeno un negozio) lascerà i dipendenti sgomenti, sconvolti e alienati.
5 - Alcuni sviluppatori semplicemente non giocano bene in coppia.
Alcune persone non si comportano o non possono comportarsi in modo appropriato in un ambiente accoppiato. Possono avere una cattiva igiene, cattive abitudini lavorative, una personalità abrasiva, un modo "forte" e "intenso", o tutta una serie di altri attributi che li rendono ottimi singoli lavoratori, ma poveri programmatori di coppie.
Puoi risolverlo? Non proprio. Cambiare il comportamento personale è difficile. Un negozio di programmazione per coppie deve essere molto attento alle assunzioni e investire molto tempo nel vedere come funziona qualcuno e se sarà in grado di lavorare bene con i propri colleghi. Discriminare di più la personalità, tuttavia, significa che l'assunzione richiederà più tempo a meno che non allenti i tuoi standard di abilità e competenza.