Calendrier de l'avent - 17 décembre - Pair Programming

Calendrier de l'avent - 17 décembre - Pair Programming

Malgré sa facilité d’adaptation à la plupart des environnemens d’entreprise, le Pair programming est souvent vu de manière très négative:

  1. Du point de vue du management par les coûts, c’est un ordinateur de moins à acheter et deux développeurs à payer pour produire autant d’heures de code qu’un seul. Et on ne peut pas donner tort à ce point de vue.
  2. Vu par un micro-manager, c’est l’occasion d’éviter de passer la journée à chatter ou à lire l’équipe vu qu’ils se surveillent l’un et l’autre.
  3. Vu par le cow boy programmer, c’est quelqu’un qui va l’embêter à lui dire comment programmer, et pire, lui prendre le clavier au bout d’un certain temps.

Et ces 3 points de vues sont vrais : c’est pour ça que pair programming est bon, mais pas seulement. On reprend:

  1. On passe le même nombre d’heure à coder une seule fois, mais à deux. Et en plus, on produit de l’entraide, de la relecture de code, du refactoring (pour avoir un code meilleur) et de l’échange de connaissances qui auraient demandé autant d’heures en plus sans ce pair programming.
  2. C’est vrai, quand on est 2, on se focalise sur le travail. Même si des récréations peuvent arriver et si des session de programmation solo viennent ponctuer le rythme du pair programming, le binome se focalise bien plus sur le code.
  3. Une vieille blague d’informaticien disait “Un bon programme, c’est comme le sexe en solitaire : sur le coup c’est agréable, mais après on se demande l’intérêt”. A deux, ce qui ressort est toujours plus valorisant, et le fait d’avoir un co-pilote oblige à se focaliser sur l’essentiel de ce que doit être un bon code : est-ce simple à relire et à comprendre?

Ca pourrait sembler du vent lorsqu’on le dit ainsi, mais le fait est que des études montrent les bienfaits du pair programming: augmentation du nombre de tests passés, moins de ligne de code pour le même résultat et ceci en améliorant la satisfaction des développeurs. Bien sûr, on augmente le coût en temps de 15% à 60%. Mais lorsqu’on compare les bénéfices avec le coût du changement au fil d’un projet, l’augmentation globale du budget n’est plus aussi évidente!