Le pair programming mort-né ?

L’un des piliers de l’eXtreme Programming, le pair programming ou programmation en paire – incorrectement appelé aussi binômage – est une pratique en voie de disparition dans les entreprises avant même d’avoir été mise à l’essai!

La programmation en paire alimente beaucoup les bruits de couloir et les discussions de réunions pour être ensuite exécutée sur le champ comme une technique exotique qui nous fait perdre en productivité.

« Tu as vu Alex et Lisa ont fait du pair programming aujourd’hui ? ». « Ouais. J’ai vu. Le patron est passé et il n’a pas aimé… ».

Encore une idée farfelue

La programmation en paire c’est deux développeurs qui s’assoient au même poste pour implémenter de façon collaborative une fonctionnalité du système. Il serait dit – d’après les même bruits de couloirs – que cette pratique rendrait l’équipe plus productive et produirait un code de qualité bien supérieure. 

Pourquoi ça ?

Dans cette configuration en paire, les développeurs dépensent plus de temps à être productif ! Ils sont constamment impliqués, peaufinant leurs idées, écartant les mauvaises très rapidement, sauvant ainsi au passage le projet de mauvais choix techniques, qui coûtent des jours voire des semaines en terme de dette technique.

Cette collaboration continue est un remède efficace contre la frustration silencieuse qu’ont les développeurs coincés sur un problème. Avez vous remarqué combien de temps un développeur peut attendre avant d’appeller un collègue à la rescousse? En paire, le progrès est constant et le flow de programmation souvent moins discontinu.

D’autre part, les développeurs se rendent mutuellement responsable pour l’utilisation des bonnes pratiques instaurées dans une équipe (standard de code, clean code, early refactor, TDD). Le processus de revue de code – qu’a la plupart des équipes pour chaque tâche terminée – est donc minimisée et demande beaucoup moins de temps en fin de cycle.

Du point de vue du fonctionnel et de l’infrastructure de l’application, la programmation en paire favorise – et impose naturellement même – le partage de la connaissance. L’appropriation collective du code (Code Collective Ownership) est ainsi accrue et la réactivité face aux bugs de production est meilleure.

Contrez l’effet tunnel et le code legacy

La journée typique d’un développeur solo est faite de micro-décisions prises seul à l’échelle de la minute et de décisions prises seul ou en équipe à l’échelle de la journée, de la semaine ou du sprint.

Par exemple, sur un projet dirons-nous classique, les micro-décisions d’un développeur sont : le nommage (modules, packages, classes, méthodes), le design orienté objet (responsabilité d’une classe, collaboration & interactions entre objets, composition ou héritage, mutabilité, etc.), l’expression juste d’un test d’integration ou unitaire, l’utilisation de librairies externes ou non, le choix des formats d’échanges, l’exploitabilité et pertinence du logging, etc.

Ce que l’on appelle effet tunnel – effet souvent invisiblement dévastateur – c’est donc l’accumulation de ces micro-décisions prises seules qui entrainent une implémentation potentiellement mauvaise, obsolète ou encore trop sophistiquée.

Sur le long terme l’effet tunnel multiplié par le nombre de développeurs d’une équipe contribue à l’émergence dans la base de code de complexité inutile (overengineering), de mauvais choix techniques, de design hasardeux, de logs inexploitables, etc.

Si nous nous entendons sur une définition du code legacy (entendez bad code) comme étant :

• le code ayant un poids physique et psychologique sur l’équipe de développement,
• le code que l’on est obligé de gérer, de déchiffrer et de comprendre au jour le jour,
• le code ne répondant pas de la meilleure façon aux besoins du syst��me d’aujourd’hui.

Alors la responsabilité partagée, le feedback instantané, les décisions mieux éclairées de la programmation par paire offre une première arme efficace contre cet effet tunnel ravageur et le code legacy.

Pièges courants à éviter

Lors de sessions de programmation en paire, impliquant des débutants en la pratique, on observe souvent deux erreurs, qui paraissent à première vue innocentes, mais qui empêchent une bonne diffusion et acceptation de la pratique.

Premièrement, lorsqu’on programme en paire, l’espace vital autour de l’ordinateur et du clavier est primordial. Il se doit d’être spacieux pour être capable d’accueillir deux développeurs qui s’échangent le clavier. Très important, la visibilité et la distance à l’écran se doit d’être la même pour les deux personnes. Évitons ainsi les bords de bureaux, la chaise bancale, une scoliose, la vue balcon sur l’écran, le sac en plein milieu ou le sandwich non terminé qui gênent l’accès au clavier.

Voici un schema pointant l’importance de la distance à l’écran pour une bonne session:

Deuxièmement, la programmation en paire se doit de suivre un rythme de changement de mains pour le clavier. Être dans le flow pour une session de 5 à 10 minutes pendant que la paire vérifie la qualité du code et l’alignement sur le fonctionnel est parfaitement acceptable. Cependant, les sessions de programmation solo prolongées où aucune idée ou feedback ne sont échangés sont à proscrire. Ce n’est pas parce que c’est notre idée que l’on se doit de l’implémenter de bout en bout. Pourquoi ne pas lâchez le clavier au milieu pour expliquer à sa paire ce qu’il en est et ce qu’il reste à faire ? L’expliquer à haute voix permet ainsi l’auto validation. 

Pour aider à trouver le rythme vous pouvez essayer le plugin Eclipse Pair Hero ou la technique du Pomodoro. 

Prenez donc garde à l’occupation de l’espace et à la répartition du temps de programmation pour les paires débutantes.

L’illusion de la productivité

Qu’est ce que cela veut dire pour un développeur d’être productif ? Évidement cela dépend de la personne à qui on le demande. Pour votre Product Owner cela correspond au nombre de stories qu’il peut inclure dans le prochain sprint. Pour votre chef de projet c’est lié à la date de sortie de la première version.

Mais pour vous, qui avez les mains dans le code et qui visitez ce musée qu’est votre base de code, la productivité revêt un tout autre sens. Elle est intimement liée aux lignes de code que vous devez manipuler tous les jours. 

Malheureusement, les gains et bénéfices d’un code propre, exprimé d’abord sous forme de tests, revu et remanié dès son écriture, sont invisibles à l’œil nu ou à l’œil profane. « Nous venons de commencer un nouveau projet from scratch et notre productivité est excellente. » Entendons-nous dire. « Excellent. Quelle chance ! » Répondons-nous. Mais retrouvons-nous dans quelques mois. La fameuse tête dans le guidon cela passe bien au début mais cela devient de plus en plus difficile à mesure qu’une base de code mal gérée grossit.

La productivité en programmation est une notion dangereuse et l’idée de programmer en paire parait bien étrange ou incertaine pour certains chefs de projet ou Product Owners. Et c’est compréhensible. C’est donc à vous de connaître les bienfaits de cette pratique sur une base de code et d’avoir les arguments pour pouvoir négocier et convaincre.

Egoless programming

Il est amusant de penser que certains développeurs acceptent volontiers de se faire imposer un système d’exploitation (Linux, Windows, …) par leur entreprise mais sont plus réticents à instaurer ou essayer une pratique censée améliorer la qualité de leur base de code, et censée les rendre plus compétents au jour le jour à travers les critiques, nouveaux conseils et techniques introduites par leur paire.

Ces refus et barrières qui se traduisent souvent par une protection du territoire, de routines, d’une frilosité face à l’inconnu et qui empêchent l’essai et l’introduction de nouvelles pratiques sont liés la plupart du temps à des facteurs personnels. La notion d’ego de la personne est un concept qui intervient beaucoup plus que l’on voudrait bien le croire dans le développement logiciel.

Ainsi la notion anglo-saxonne d’Egoless Programming a été introduite pour la première fois en 1998 dans le livre The Psychology of Computer Programming. Par définition, l’Egoless Programming est un style de programmation dans lequel les facteurs personnels – ego – sont minimisés. Dans ce livre, Jerry Weinberg explique entre autre que lorsque l’on produit une partie de code, ce code fait plus ou moins consciemment partie de nous.

Ainsi toute critique de ce code est une critique de nous même. Ouch ! L’ego en prend un coup. L’idée est tout simplement de comprendre cela pour pouvoir le dépasser. Néanmoins, cela reste un exercice personnel.

Certains développeurs vont s’opposer au pair programming sans même essayer. Pourquoi ? Ils n’ont pas eu le temps d’essayer et n’ont donc pas d’avis. Ils ont essayé et la nature de leur projet ne le leur permettait pas. Ce sont des raisons parfaitement valables. Toutefois, d’autres le sont moins.

Un développeur doit être capable de produire du code de qualité tout en acceptant les critiques potentielles. Son code doit être potentiellement jetable sans que cela l’affecte personnellement.

Introduire cette pratique dans mon équipe

Tout seul, la programmation en paire, vous en conviendrez, c’est très difficile !

Pour réussir l’introduction de la programmation en paire dans votre équipe, vous serez plus convaincant et efficace si vous l’avez pratiqué vous même auparavant selon le principe du lead by example. Certainement quelqu’un dans votre équipe souhaite aussi découvrir cette pratique. Profitez-en donc pour vous y aguerrir tous les deux pendant quelques temps pour ensuite l’introduire petit à petit au reste de l’équipe.

Vous pouvez aussi pratiquer le pair programming en dehors de l’entreprise, en participant à des code retreats ou à des randoris – Xebia en organise.

Une autre façon de tester et d’adopter de façon plus douce la programmation en paire dans votre entreprise, c’est lorsqu’un nouveau développeur rejoint une équipe: ne lui attribuez aucun bureau ou espace personnel et faites le programmer en paire pendant 1 à 2 semaines avec le reste de l’équipe.

Cela introduira le concept pour tous les membres de l’équipe. Le nouveau venu montera très rapidement en compétence sur la base de code et le fonctionnel. Bien sûr, vous en aurez parlé auparavant à votre équipe et vous aurez obtenu en amont l’accord du nouvel arrivant.

Formez vos bataillons

Bref, voilà encore donc une pratique exotique à première vue mais utilisée de plus en plus outre-atlantique et outre-manche. Des compagnies de conseils (ex: Pivotal Labs pour n’en citer qu’une) n’envoient d’ailleurs leurs consultants que par paires sur un projet ! Certaines sont même passées au hot desking : plus de bureaux personnellement attribués (ex: Talk Talk, BI-SAM). Le matin vous décrochez votre story du Scrum board pour voir avec qui vous allez passer votre journée et sur quel poste !

Si votre responsable vous apostrophe : « Quoi ! Deux programmeurs faisant le travail d’un seul ?? ». Pour gagner du temps répondez-lui: « C’est plus efficace qu’un programmeur devant faire le travail pour deux figurez-vous ! ». 

Puis dans un deuxième temps, souvenez-vous de ce que l’on a discuté tout au long de cet article et expliquez-lui les bienfaits : de la responsabilité partagée, du feedback instantané, de décisions mieux éclairées, de passer plus de temps à être productif, d’avoir moins de frustration, d’un progrès constant, d’un respect des bonnes pratiques, du partage de connaissances, de la formation des juniors et de la remise en question parfois des plus seniors.

Allez ! Pour vous donner du courage voici un petit chant pour le pair programmeur:

Aux claviers, développeurs
Formez vos bataillons
Codons, codons
Qu’un code sûr
Abreuve nos repos