index.md 8.5KB
title: Être develop-père
url: http://makina-corpus.com/blog/metier/2015/etre-develop-pere
hash_url: 1da7a055cf
Précision sur le vocabulaire: les termes "père" et "paternité" employés ici doivent être compris dans leur signification générique et non pas spécifiquement masculine.
Le dévelop-père et son logiciel
Le développement logiciel n'est pas un acte de production ordinaire.
D'abord, il s'agit d'un processus de création complet : on part de rien et on arrive à quelque chose de concret qui n'existait pas avant, et cela par notre seule intervention (à la différence d'un ingénieur qui dessine un plan, alors que la construction effective est assurée par un ouvrier).
C'est aussi un processus long et itératif : on doit revenir plusieurs fois sur les mêmes parties, pour les améliorer ou les compléter petit à petit.
Et ces spécificités engendrent assez naturellement un sentiment qu'on peut qualifier de paternel entre le développeur et son logiciel : on prend soin de son code, on essaie de l'améliorer, et on en tire une certaine fierté. On devient son dévelop-père.
Le dévelop-père est celui qui apprend à marcher à un logiciel
Si on veut s'amuser avec les mots, on remarquera qu'on dit qu'un logiciel marche, et son dévelop-père est justement celui qui lui apprend à marcher.
Ce sentiment paternel dérive du statut d'adulte du développeur (voir Majorité du développeur dans "Otium et negotium dans l'industrie du logiciel"), ce n'est pas un enfant ou un mineur, il se sent responsable, et il faut favoriser ce statut car il est très important pour le futur du logiciel, il garantit sa survie à long terme. Étant en position de responsabilité, le développeur va être attentif au comportement de son logiciel, veiller à son maintien en bon état. Il sera à son écoute, peut-être même plus à son écoute qu'à l'écoute de ses utilisateurs (ce qui peut d'ailleurs induire un effet pervers).
Notons que cela ne dépend pas du niveau du développeur, qu'on soit débutant ou aguerri, le même sentiment va apparaître. D'ailleurs, il arrive qu'on confie un développement à un développeur ayant peut-être une haute opinion de son niveau, ou en tout cas qui n'aime pas le logiciel qu'on lui demande d'écrire. Dans de tels cas, la relation paternelle ne va pas se tisser et le logiciel sera à terme mauvais (et certainement moins bon qu'un logiciel fait avec amour par un développeur éventuellement moins habile).
La paternité plurielle dans l'opensource
Les communautés opensource rassemblent des développeurs d'un même logiciel. Peu d'entre eux sont les développeurs originels du logiciel en question.
Pourtant ils ont acquis ce sentiment de responsabilité paternelle vis-à-vis du logiciel. Il leur a été transmis par les contributeurs passés ou existants. Une communauté opensource s'appuie sur des mécanismes familiaux, on y accueille des membres à qui on fait confiance pour assurer l'avenir de la descendance.
Les communautés opensource sont avant tout des structures d'adoption
Les communautés opensource sont donc avant tout des structures d'adoption, elles garantissent qu'un logiciel n'est jamais orphelin.
Plus que le nombre de personnes impliquées dans une communauté, le vrai indicateur de la bonne santé d'un logiciel opensource est la force et la persistance de ce sentiment de responsabilité partagée, et inversement sa faiblesse est un signe de dépérissement à venir.
Assurer un cadre paternel pour les logiciels privés
Autant les logiciels opensource ont toutes les chances de garder assez de pères autour pour assurer leur bonne croissance (car c'est justement la raison d'être des communautés), autant cela peut être délicat pour un logiciel créé dans un cadre commercial par une société de service pour un de ses clients.
Même si la relation paternelle sera sûrement apparue pour le développeur initial, il y a de fortes chances qu'au grès des fins de contrats et/ou des ré-affectations, il ne soit plus en charge du logiciel qu'il a créé.
C'est un vrai problème car alors le logiciel ne sera alors que "maintenu", c'est-à-dire qu'on répondra à ses besoins vitaux, mais on ne l'élèvera plus, il en souffrira et ses utilisateurs le sentiront. L'issue habituelle est soit un abandon progressif, soit une décision de refonte, aboutissant donc à la refondation d'une nouvelle paternité (c'est d'ailleurs la réponse quasi systématique que nous faisons à nos clients demandant la reprise d'un logiciel existant : on préfère repartir de zéro car on ne peut pas et on ne veut pas adopter le logiciel existant).
Un enjeu fort pour les sociétés de service est donc de réussir à transmettre correctement la paternité à l'équipe suivante.
Un logiciel existant a plus de chances de survie s'il a un bon père adoptif que s'il a une excellente documentation technique
La solution habituelle à ce problème consiste à s'assurer que le logiciel est correctement documenté, que le code est commenté et testé. On peut aussi organiser une période de formation qui sert de transfert de compétence. C'est une approche formelle qui oublie l'aspect sentimental du problème et en cela elle est relativement faible et inefficace. Un logiciel existant a plus de chances de survie s'il a un bon père adoptif que s'il a une excellente documentation technique.
En nous basant sur l'exemple de l'opensource, nous avons expérimenté un moyen de transfert de paternité efficace. De la même manière qu'une communauté accueille ses nouveaux contributeurs en les encadrant, et les guidant, de sorte qu'ils se sentent pris en charge dans un système familial, qui va les conduire finalement à assurer à leur tour un rôle parental, nous avons choisi d'intégrer nos clients au processus de développement le plus tôt possible et sur le même mode.
Travaillant en mode agile, nous intégrons dès la première itération au moins un membre de l'équipe cliente, même s'il n'a qu'une expérience limitée des technologies utilisées. La relation que nous établissons avec lui n'est pas celle d'un fournisseur avec son client ou d'un formateur avec son élève, mais celle d'un contributeur senior avec un contributeur débutant : nous lui confions des tâches simples afin de lui faire découvrir nos techniques et nos bonnes pratiques, nous nous occupons des tâches ingrates et nous démystifions ce qui lui semble compliqué ou effrayant. Au fil des itérations, nous l'incitons à s'améliorer et à prendre en charge des tâches plus complexes.
Au terme du processus, au contraire d'un développeur à qui on dirait: "Tu vas t'occuper de ce logiciel, voici la doc, il y a tout ce qui faut" et qui se sentirait abattu, contraint, et dans une certaine mesure infantilisé et donc dé-responsabilisé, le développeur a le sentiment d'avoir progressé avec ce nouveau projet, et ayant effectivement grandi, il va pouvoir assumer sa responsabilité de nouveau père pour le logiciel.
Conclusion
Cet article s'appuie sur plusieurs expériences différentes: des cas positifs comme le développement dans la communauté Plone ou avec nos clients tels que décrit ci-dessus, mais aussi des cas négatifs de cassure de paternité qu'on a pu connaître sur certains projets.
Et après analyse, il nous a semblé que l'approche habituelle s'appuyant sur la documentation, les processus qualité, et toute l'artillerie qui s'y rapporte, oblitère complètement cette notion de paternité qui est absolument déterminante pour la pérennité des logiciels.
Donc sans bien entendu prétendre que les développeurs sont des personnes hyper-sensibles dont il faut gérer les émotions avec délicatesse, notre objectif est simplement de remettre en perspective les méthodologies classiques parfois trop formelles avec la réalité sensible des choses.