Quels sont les inconvénients possibles de la programmation par paires? [fermé]

La programmation par paires est assez célèbre de nos jours.

Il présente plusieurs avantages comme:

1. Programmes avec moins de bugs.
2. Le coût de maintenance post-production est beaucoup moins élevé.
3. Les pratiques établies sont remises en cause, entraînant l'émergence de nouvelles idées.
4. Les programmeurs apprennent les uns des autres.
5. Les programmeurs développent des compétences générales.

Mais quels sont les inconvénients de la programmation par paires?

Bien que la programmation par paires ait acquis une réputation considérable, elle présente également plusieurs écueils.

Certains d'entre eux sont les suivants:

1. Dans la programmation par paires, vous ne pouvez pas vous asseoir et auto-évaluer votre propre code.
2. L'un des deux peut cesser d'être activement engagé.
3. Le pilote doit "programmer à haute voix". La programmation silencieuse réduit les avantages.
4. Il en coûte plus d'heures de travail pour produire les mêmes fonctionnalités. Un équilibre doit être maintenu entre la qualité du code et l'augmentation des coûts de codage.
5. Un phénomène de «surveillance du maître» peut survenir lorsqu'un programmeur expérimenté et un programmeur novice s'associent. Le membre novice peut devenir l'observateur, le membre expérimenté effectuant la plupart du codage.
6. Lorsque deux utilisateurs expérimentés s'associent, un phénomène d '«ego de développeur» peut survenir, chaque membre essayant de pousser ses propres idées.

J'ai essayé plusieurs fois la programmation par paires, y compris dans une organisation qui a (brièvement) envisagé de la déployer comme un processus obligatoire pour tous les ingénieurs (vous pouvez deviner à quel point cette idée a bien fonctionné). Personnellement, je détestais ça.

Les raisons que j'énumère ci-dessous ne sont que mes expériences subjectives et je ne peux pas «mesurer» leur impact en termes concrets. Mais ici, c'est pareil:

1 - Avoir un «navigateur» et un «chauffeur» n'aide que si le premier est vocal et que le second écoute.

Nous avons tous rencontré des développeurs qui sont têtus, zélés à propos de certaines préoccupations théoriques ou pathologiquement incapables - psychologiquement - de `` jeter '' de vieux travaux lorsque quelqu'un suggère un problème avec cela. Et nous connaissons tous des individus trop timides ou hésitants pour soulever des préoccupations ou suggérer des cas de coin.

Lorsque ces types de développeurs sont associés, le navigateur joue rapidement un rôle passif, et vous vous retrouvez avec une seule programmation avec une révision automatique du code. Il s'agit d'un gaspillage monumental de ressources.

2 - Le jumelage empêche la créativité.

Contrairement à ce qui était auparavant ressenti à propos de la valeur du «brainstorming de groupe», le consensus est de nos jours que le travail de connaissance créative requiert indépendance et autonomie . Lorsque vous travaillez seul, vous pouvez rapidement pirater une idée folle pour voir si c'est réellement possible. Vous pouvez assembler sans un mot un étrange prototype, et si vous échouez, cela n'a pas d'importance, car personne ne le sait .

Comparez cela à l'appariement: lorsque je veux essayer un nouveau concept, je dois convaincre mon partenaire, lui parler de la mise en œuvre, étape par étape, et espérer qu'il ne me jugera pas s'il échoue. Ce genre d'environnement est toxique pour créer de nouvelles idées.

3 - Conception du plus petit dénominateur commun.

Lorsqu'une paire ne peut pas faire émerger de nouvelles idées, comme ci-dessus, ou lorsque les individus ne peuvent pas s'entendre sur un principe fondamental de la façon dont une fonctionnalité doit être conçue, ce qui en ressort est un design confus qui tente de compromettre et de ne satisfaire personne.

Si vous associez un développeur qui construit des abstractions de programmation fonctionnelles merveilleuses, éloquentes et vers le ciel avec un monstre de performance rapide et sale, le code qu'ils produiront ensemble ne sera généralement ni terriblement élégant ni particulièrement rapide.

4 - Manque d'autonomie et de transparence violente.

La transparence violente est une phrase que j'ai tirée d'une polémique modérément célèbre (et assez controversée) contre la méthodologie Scrum. Il décrit la manière dont certaines organisations infantilisent les développeurs et les traitent avec la suspicion normalement réservée aux travailleurs non professionnels.

Quoi que vous pensiez des `` inconvénients '' de rendre le travail des développeurs entièrement transparent (et vous ne serez peut-être pas d'accord pour dire que c'est en fait un préjudice), de nombreuses personnes apprécient leur autonomie et leur capacité à travailler seules, en qui elles ont confiance pour faire la bonne chose. C'est un besoin psychologique important, et forcer les développeurs à s'associer (comme je l'ai vu se produire dans au moins un magasin) laissera les employés consternés, contrariés et aliénés.

5 - Certains développeurs ne jouent tout simplement pas bien par paires.

Certaines personnes ne se conduisent pas ou ne peuvent pas se conduire correctement dans un environnement jumelé. Ils peuvent avoir une mauvaise hygiène, de mauvaises habitudes de travail, une personnalité abrasive, une manière `` forte '' et `` intense '', ou toute une série d'autres attributs qui font d'eux de bons travailleurs individuels, mais de mauvais programmeurs.

Peux-tu le résoudre? Pas vraiment. Changer le comportement personnel est difficile. Un magasin de programmation en binôme doit faire très attention à l'embauche et investir beaucoup de temps pour voir comment quelqu'un travaille et s'il pourra bien travailler avec ses pairs. Discriminer plus durement sur la personnalité, cependant, signifie que l'embauche prendra plus de temps, sauf si vous assouplissez vos normes en matière de compétences et d'expertise.

Cela dépend de votre situation ou de votre point de vue.

La programmation en binôme est bonne pour l'organisation. Mais est-ce bon pour l'individu?

Après tout, c'est une méthode de réduction des coûts (rétroaction précoce) et de productivité; Il ne s'agit pas de vous mais du projet, du produit, de l'entreprise ($$).

Bien que vous puissiez avoir des avantages personnels, ils ne sont ni la raison ni la fin de toute méthodologie de développement. La programmation en couple (à temps plein), par exemple, vous empêche également de vous relâcher, de surfer, etc., vous devez justifier vos pauses auprès de votre partenaire.

Votre partenaire (rotatif) sera la meilleure caméra de surveillance: l'intensité du travail augmente.

Ou bien, en distribuant les connaissances, l'individu devient moins risqué pour l'entreprise (par exemple, ne peut pas quitter l'entreprise avec les connaissances essentielles) et a moins de «moyens de négociation».

Je suis sûr que vous trouvez plus de points en lisant des articles affirmatifs de manière plus critique de VOTRE situation / point de vue réel dans l'entreprise plutôt que du point de vue de votre manager.

Presque toutes les méthodologies sont écrites du point de vue du gestionnaire.

1. Soudain, vous devez maintenant dire à quelqu'un quand vous voulez aller aux toilettes ou prendre un café. Au moins, il n'est pas nécessaire de demander la permission.

2. Vous devez vous conformer aux normes d'hygiène de l'autre personne.

En plus d'autres réponses:

1. De nombreuses entreprises pour lesquelles j'ai travaillé délivrent à leurs programmeurs des ordinateurs portables (basés sur le site des clients - plus facile de garder l'équipement en sécurité s'il est ramené à la maison après le travail, être en mesure de faire le petit boulot de la maison sur VPN en un rien de temps, etc.) De nombreuses années Il y a déjà, j'avais des problèmes à voir sur l'écran du portable d'une autre personne (le "conducteur") du point de vue de l'épaule - l'âge n'améliorera pas cela (et certains écrans deviennent difficiles à lire en dehors de l'angle de vue idéal dans tous les cas).

   Les programmeurs de paires auront donc besoin d'écrans suffisamment grands, ce qui augmentera le coût du matériel et limitera l'adaptabilité à l'emplacement. Peut ne pas être un problème pour certains, dans d'autres cas, ce sera un problème.

2. J'ai également constaté que les différences dans les préférences d'hygiène personnelle (y compris le tabagisme, l'alimentation et la boisson), ainsi que les conflits de personnalité, sont tenus d'entraver la productivité. Il est assez facile de dire à deux programmeurs de "sucer et s'entendre", souvent cela conduira les gens à garder la bouche fermée et à se saboter silencieusement via des actions passives-agressives pour évacuer leurs ressentiments l'un envers l'autre.
3. Bruit. Pour ma part, j'aime un environnement de travail calme. Je ne peux pas imaginer le bavardage constant de certains groupes de programmeurs de paires (car vous devez parler pour la communication). Même la musique vocale sur mon casque a tendance à interférer avec ma concentration (instrumentaux fades pour une écoute de bureau ...). Je suppose que cela peut être atténué en quittant le bureau ouvert omniprésent pour des salles de bureau dédiées à 2 personnes, mais cela fera encore augmenter les coûts.

Anecdotes pour votre amusement:

• Un ancien employeur a fait venir un entrepreneur d'un autre pays (le tout pour rester anonyme pour protéger les coupables). L'employeur a fourni le logement mais pas le transport. Étant donné que ledit entrepreneur vivait le long de mon itinéraire de travail, je me suis porté volontaire pour le ramasser et le déposer à nouveau. Disons que son hygiène personnelle n'était pas au même niveau que ce à quoi je suis habitué, et il fumait aussi beaucoup ("le plus fort!") Alors que je ne le fais pas. Lors de notre voyage de 15 minutes au bureau, j'ai gardé ma fenêtre baissée - même en hiver - ce qui n'a pas empêché ma voiture de sentir comme un fumoir périmé après le passage de 3 mois du collègue (non, il n'a pas fumé dans la voiture , mais il l'a fait en m'attendant).
• Nous n'avons pas non plus fait de programmation par paires, mais nous nous sommes assis côte à côte à une table de conférence (pendant un certain temps). Après environ un mois, il y avait un joli anneau marron sur le faux bois de la table autour de la position de la main de la souris du collègue. À ce moment-là, j'ai eu un bureau ouvert juste à côté de la zone ouverte du centre d'appels, que j'ai préféré (avec l'aide de mes écouteurs).
• Ensuite, il y a la boisson de bureau omniprésente: le café. Bien que je le boive, je peux m'entendre sans et ne bois pas aussi souvent que les autres collègues. Les respirations à courte distance peuvent être assez désagréables - similaires à l'odeur de tasse vide oubliée. Appelons le parfum "muggy" ...

Je pense que la programmation en binôme échoue pour des raisons sociales et pratiques. Essentiellement, vous demandez à une personne de travailler sous surveillance constante et à l'autre de ne faire que des trous.

Ce qui se passe inévitablement après un certain temps, c'est que la paire se sépare pour `` vérifier les e-mails '' ou `` vous continuez de vérifier mal ce problème en direct '', etc.

Plutôt que d'améliorer la sortie du code, le volume est diminué. À la fois pour des raisons pratiques `` J'ai besoin d'aller déjeuner / réunion désynchronisé avec vous '' et social `` Je vais juste attendre que Bob termine ce qu'il fait avant de demander à nouveau de me jumeler, je ne veux pas être perçu comme le harcelant ''

En ce qui concerne les avantages tant vantés, il existe de nombreuses pratiques courantes qui permettent de les atteindre de manière plus simple et efficace

Dire à deux développeurs seniors de faire une "programmation douloureuse" s'ils sont convaincus que l'on peut faire le travail est imo on du plus gros désavantage.