Quali sono i possibili svantaggi della programmazione della coppia? [chiuso]

Sebbene la programmazione delle coppie abbia acquisito una notevole reputazione, ha anche diversi problemi.

Alcuni di questi sono i seguenti:

1. Nella programmazione a coppie non puoi sederti e autovalutare il tuo codice.
2. Una delle coppie potrebbe smettere di essere attivamente impegnata.
3. Il driver deve "programmare ad alta voce". La programmazione silenziosa riduce il vantaggio.
4. Costa più ore uomo per produrre le stesse funzionalità. L'equilibrio deve essere mantenuto tra la qualità del codice e l'aumento del costo di codifica.
5. Un fenomeno "guarda il maestro" può sorgere quando un programmatore esperto e un principiante si accoppiano. Il membro novizio può diventare l'osservatore con il membro esperto che completa la maggior parte della codifica.
6. Quando due utenti esperti accoppiano, può sorgere un fenomeno di "ego dello sviluppatore", con ogni membro che cerca di spingere le proprie idee.

Ho tentato di eseguire una paia di pairing diverse volte, anche in un'organizzazione che (per un breve periodo) ha pensato di implementarla come un processo obbligatorio per tutti gli ingegneri (si può intuire quanto sia stata corretta l'idea). Personalmente, l'ho disprezzato.

Le ragioni che elenco qui sotto 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à.

Tutti abbiamo incontrato sviluppatori ostinati, zelanti su alcune preoccupazioni teoriche o patologicamente incapaci - psicologicamente - di "buttare via" il vecchio lavoro quando qualcuno suggerisce un problema con esso. E tutti sappiamo che persone troppo timide o diffidenti sollevano preoccupazioni o suggeriscono casi angosciosi.

Quando questi tipi di sviluppatori sono accoppiati, il navigatore assume rapidamente un ruolo passivo e ciò che si ottiene è la sola programmazione con una revisione automatica del codice. Questo è un enorme spreco di risorse.

2 - L'associazione impedisce la creatività.

Contrariamente a quanto si pensava in passato del 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 mettere insieme qualche idea pazza per vedere se è effettivamente fattibile. Puoi assemblare senza parole qualche strano prototipo e, se fallisci, non importa, perché nessuno lo sa .

Confronta questo con l'abbinamento: quando voglio provare un nuovo concetto, devo convincere il mio partner, parlarne attraverso l'implementazione, passo dopo passo, e sperare che non mi giudicheranno se fallisce. Quel tipo di ambiente è tossico per creare nuove idee.

3 - Design del minimo comune denominatore.

Quando una coppia non può inventare nuove idee, come sopra, o quando gli individui non sono d'accordo su alcuni principi fondamentali su come una caratteristica dovrebbe essere progettata, ciò che viene fuori è un disegno confuso che tenta di compromettere e soddisfare nessuno.

Se accoppi uno sviluppatore che costruisce astrazioni di programmazione funzionali meravigliose, eloquenti, al cielino con un maniaco di prestazioni fast-and-dirty, il codice che produrrà insieme non sarà né particolarmente elegante né particolarmente veloce.

4 - Mancanza di autonomia e trasparenza violenta.

Trasparenza violenta è una frase che ho strappato da una polemica moderatamente famosa (e piuttosto controverso) 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 dei "danni" di rendere il lavoro degli sviluppatori completamente trasparente (e potresti non essere d'accordo sul fatto che sia effettivamente un danno), molti individui apprezzano la loro autonomia e la loro capacità di lavorare da soli, fidati di fare la cosa giusta. È un importante bisogno psicologico 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 possono o non possono comportarsi in modo appropriato in un ambiente associato. Possono avere una cattiva igiene, cattive abitudini lavorative, una personalità abrasiva, un modo "strong" e "intenso", o tutta una serie di altri attributi che li rendono buoni lavoratori individuali, ma poveri programmatori di coppia.

Puoi risolvere questo? Non proprio. Cambiare il comportamento personale è difficile. Un negozio per la programmazione di coppie deve fare molta attenzione all'assunzione e dedicare molto tempo a vedere come funziona qualcuno e se sarà in grado di lavorare bene con i colleghi. Discriminare di più sulla personalità, tuttavia, significa che l'assunzione richiederà più tempo se non allenti i tuoi standard in termini di capacità e competenze.

Dipende dalla tua situazione o prospettiva.

La programmazione accoppiata fa bene all'organizzazione. Ma è buono per l'individuo?

Dopotutto è un metodo di riduzione dei costi (feedback anticipato) e produttività; Non si tratta di te, ma del progetto, prodotto, azienda ($$).

Sebbene tu possa avere vantaggi personali, non sono la ragione o la fine di alcuna metodologia di sviluppo. La programmazione a coppie (a tempo pieno), ad esempio, ti impedisce anche di rallentare, navigare, ecc., Devi giustificare le tue pause al tuo partner.

Il tuo partner (rotante) sarà la migliore telecamera di sorveglianza: l'intensità del lavoro aumenta.

Oppure, distribuendo le conoscenze, l'individuo diventa meno rischioso per l'azienda (ad es. non può lasciare l'azienda con conoscenze essenziali) e ha meno "chip di contrattazione".

Sono sicuro che trovi più punti leggendo gli articoli affermativi in modo più critico dalla TUA situazione reale / punto di vista in azienda piuttosto che dal punto di vista del tuo manager.

Quasi tutte le metodologie sono scritte dal punto di vista del gestore.

1. All'improvviso devi dire a qualcuno quando vuoi andare in un bagno o bere un caffè. Almeno non c'è bisogno di chiedere il permesso.

2. Devi fare i conti con gli standard igienici dell'altra persona.

Oltre alle altre risposte:

1. Molte aziende per cui lavoro hanno emesso i propri programmatori con laptop (basati sul sito dei clienti): è più facile tenere al sicuro l'attrezzatura se portati a casa dopo il lavoro, essere in grado di fare il lavoro da casa su VPN in un pizzico, ecc. Molti anni fa ho già avuto problemi a vedere sullo schermo del laptop di un'altra persona (il "conducente") dal punto di vista della spalla - l'età non migliorerà (e alcuni schermi diventano difficili da leggere al di fuori dell'angolo di visione ideale in ogni caso ).

   Quindi i programmatori di coppia avranno bisogno di schermi sufficientemente grandi, il che aumenterà il costo dell'hardware e limiterà l'adattabilità alla posizione. Potrebbe non essere un problema per alcuni, in altri casi sarà un problema.

2. Ho anche scoperto che le differenze nelle preferenze di igiene personale (incluso fumare, mangiare e bere), così come gli scontri di personalità, sono destinate a ostacolare la produttività. È abbastanza facile dire a due programmatori di "succhiarlo e andare d'accordo", spesso questo porterà le persone a tenere la bocca chiusa e a sabotare silenziosamente l'un l'altro attraverso azioni passive-aggressive per sfogare i loro risentimenti reciproci.
3. Noise. Io, per esempio, come un ambiente di lavoro silenzioso. Non riesco ad immaginare le continue chiacchiere da parte di alcuni gruppi di programmatori di coppie (dato che devi parlare per comunicare). Anche la musica vocale sulle mie cuffie tende ad interferire con la mia concentrazione (blandi strumentali per l'ascolto in ufficio ...). Immagino che questo possa essere mitigato spostandoti dall'onnipresente ufficio open space a due uffici dedicati, ma questo farà salire di nuovo i costi.

Aneddoti per il tuo divertimento:

• Un precedente datore di lavoro una volta ha ottenuto un appaltatore da un altro paese (tutto per rimanere anonimo per proteggere i colpevoli). Il datore di lavoro ha fornito alloggio ma non trasporto. Dato che l'appaltatore ha vissuto lungo il mio percorso verso il lavoro, mi sono offerto volontario per prenderlo e lasciarlo di nuovo. Diciamo che la sua igiene personale non era dello stesso livello di quello a cui sono abituato, e ha anche fumato pesantemente ("il più strong!") Mentre io no. Durante il nostro viaggio di 15 minuti in ufficio ho tenuto il finestrino abbassato - anche in inverno - che non ha impedito alla mia auto di annusare come una stanza per fumatori stantia dopo lo stint di 3 mesi del collega (no, non ha fumato in macchina , ma l'ha fatto mentre mi aspettava).
• Inoltre non abbiamo fatto la paia di programmazione, ma ci siamo seduti uno accanto all'altro al tavolo di una conferenza (per un po 'di tempo). Dopo circa un mese, c'era un bel anello marrone sul finto legno del tavolo attorno alla posizione della mano del mouse del collega. A quel punto ho avuto un open desk proprio accanto all'area open space del call center, che ho preferito (con l'aiuto delle mie cuffie).
• Poi c'è l'onnipresente bevanda da ufficio: il caffè. Anche se lo bevo, posso andare avanti senza e non bere più spesso di altri colleghi di lavoro. I respiri a distanza ravvicinata possono essere piuttosto sgradevoli - come l'odore della tazza dimenticata vuota. Chiamiamo la fragranza "afosa" ...

Penso che la programmazione delle coppie fallisca per ragioni sociali e pratiche. In sostanza, stai chiedendo a una persona di lavorare sotto costante sorveglianza e l'altra di non fare altro che bucare i buchi.

Ciò che inevitabilmente accade dopo un po 'è che la coppia si divida per "controllare le email" o "tu controlli male su quel problema in diretta" ecc.

Invece di migliorare l'output del codice, il volume diminuisce. Sia per motivi pratici 'Devo andare a pranzo / incontro fuori sincrono con te' e social 'Ill aspetta solo che bob finisca quello che sta succedendo prima di chiedere di accoppiare di nuovo, non voglio essere visto come fastidioso lui'

Per quanto riguarda i vantati vantaggi, esistono molte pratiche comuni che consentono di raggiungerle in modi più semplici ed efficaci

Dire a due sviluppatori senior di fare una "programmazione del dolore" se sono sicuri che si possa fare il lavoro è il più grande svantaggio.