Depuis plusieurs années que je suis consultant chez OCTO, j’ai eu plusieurs fois l’occasion d’auditer le fonctionnement d’équipes de développement, que ce soit pour des audits internes ou des due diligences techniques.

Dans ce contexte,  j'ai pu constater un comportement récurrent dans de nombreuses entreprises, notamment chez les startups numériques.

L’origine de la consanguinité logicielle

Le fonctionnement en vase clos

Ma définition :

• Le développement du produit est initialement mené par un développeur ou une développeuse sortant de sa formation initiale ou étant faiblement expérimenté·e (parce que moins chèr·e et/ou plus malléable et corvéable)
• Le projet grandissant petit à petit, une équipe est constituée avec d'autres personnes "peu chères"
• La montée en compétence des nouveaux arrivants et nouvelles arrivantes est assurée notamment par le premier développeur ou la première développeuse, quand elle est vraiment assurée, ce qui n’est pas toujours le cas...
• L'argent étant un enjeu, le temps étant de l'argent (ou plus précisément, des coûts salariaux), il n'y a (quasiment) pas de temps pour se former ou faire de la veille (et cerise sur le gateau, quand on se forme, on ne produit pas). Ou, lorsqu’il y en a, il est majoritairement utilisé pour de la montée en compétence technique (apprentissage de framework, d'outils, de langages …)

C'est ce que j'appelle faire du développement en vase clos. En effet, à aucun moment l’équipe n’a reçu de nouvel apport extérieur, aucune nouvelle personne ne venant partager avec l'équipe ses expériences passées et son savoir-faire.

Les conséquences du vase clos

A l’instar des pharaons égyptiens et de certaines familles royales qui souhaitaient préserver la "pureté de leur sang" et qui pratiquaient la consanguinité, les systèmes informatiques ainsi conçus comportent malheureusement de nombreuses tares (liste non exhaustive, sur la base d’exemple que j'ai rencontrés) :

• réinvention de la roue :
  • ORM maison, framework web maison, outil de build ou d’intégration continue maison ;
• surcouche ou fork de framework open source, sans que ce soit pertinent :
  • Et bien souvent, sans jamais réintégrer les mises à jour de la base de code initiale (souvent justement parce que le code a été trop modifié, empêchant donc les montées de versions)
• absence/manque de tests automatisés (voir même de tests tout court) ;
• lacunes architecturales ;
• forte complexité :
  • par une recherche quasi systématique de généricité,
  • par un manque de maitrise du paradigme de programmation utilisé,
  • par hétérogénéité du code (pas de mise en place, de partage ou de respect des standards)

En règle générale, plus le développement du produit se fait rapidement/dans l’urgence, plus ces tares sont nombreuses.

Ce mécanisme n’est pas réservé aux start-ups, j'ai pu constater les mêmes problèmes dans des sociétés utilisant des développeurs ou des développeuses en prestation dont le critère principal de sélection est le tarif journalier moyen.

L’origine idéologique de ce mode de fonctionnement

Ce mode de fonctionnement repose sur quatre raisonnements erronés (et certainement plus), appliqués de manière plus ou moins consciente :

1. Le développement est uniquement un savoir-théorique :
   • Par extension, on peut se former par soi-même.
   • Par extension, seule l'acquisition de nouveaux savoirs est importante pour être un bon développeur.
2. D’un point de vue individuel, le développement s'apparente à un travail individuel d’exécution, réalisable en parallèle ou en série.
   • Par extension, les développeurs et développeuses sont facilement interchangeables.
   • Par extension, N développeurs et développeuses vont N fois plus vite qu'un développeur ou une développeuse seul·e.
3. L'évolution du développeur, c'est devenir chef de projet.
   • Par extension, gagner de l'expérience en développement n'a que peu de valeur pour le futur.
   • Par extension, être développeur ou développeuse n'est pas une carrière.
4. Le développement est un coût.
   • Par extension, il doit avoir une fin.
   • Par extension, l'important c'est la tenue du cahier des charges, peu importe ce qui se passe après la livraison.
   • Par extension, moins les développeurs sont chers, mieux c’est.

Sortir de la consanguinité logicielle

Une autre alternative sur le développement logiciel

Par opposition aux quatre raisonnements développés dans le précédent paragraphe, mon opinion est la suivante :

1. Le développement est un ensemble de savoir-théorique, de savoir-faire et de savoir être, en perpétuelle évolution.
   • Par conséquent, il est nécessaire d'être accompagné par un sachant pour acquérir ces savoir-faire.
   • Par conséquent, l'apprentissage des pratiques de développement est au moins tout aussi important que la montée en compétence sur un langage, un framework ou un outil.
2. D'un point de vue individuel, le développement est une forme de travail sans pareil, au carrefour de plusieurs autres :  l'ingénierie, l'artisanat, le design, l'architecture, l’écriture, la communication, l’écoute …. D'un point de vue collectif, je trouve que cela se rapproche davantage de la réalisation cinématographique (pluri-disciplinarité, importance de la communication et des échanges, …).
   • Par conséquent, une équipe de développement est d'autant plus performante qu'elle est pluri-disciplinaire.
   • Par conséquent, l'ajout de développeurs ou de développeuses à l'équipe ne va probablement pas permettre d'aller plus vite (cf Mythical Man Month).
3. Le développement est une carrière.
   • Par conséquent, l'expérience en développement est très importante (même si le "10x developer" n'existe pas (cf The Leprechaun of Software Development).
   • Par conséquent, ce n'est pas parce qu'on est développeur à 40 ans et plus qu'on a raté sa vie…
4. Le développement est un asset stratégique.
   • Par conséquent, il doit être piloté par son ROI et non son budget.
   • Par conséquent, il faut réfléchir à sa maintenabilité à travers le temps et donc sa qualité.

Investir sur ses équipes

Ne pas investir sur l'apprentissage des développeurs et des développeuses aux pratiques de développement puis ne pas les accompagner dans leur progression, c'est les empêcher de développer leurs talents en programmation. Certaines sociétés assument ce parti pris, mais en payent souvent les conséquences à moyen ou long terme quand leur time to market explose ou qu’ils sont incapables de maintenir leurs applications.

Dans le même ordre d'idée, les écoles/formations en programmation dans lesquelles il n'y a aucun accompagnement par un développeur ou une développeuse expérimenté·e et où l'auto-formation et l'évaluation par les pairs sont la règle ne peuvent que transmettre une vision biaisée. En effet, cela peut donner l'impression aux étudiants et étudiantes qu'une progression uniquement par soi-même et/ou en vase clos est possible. Or, comme je l'ai déjà dit en introduction, c'est se condamner à accepter d'évoluer dans des entreprises qui prônent, consciemment ou pas, la consanguinité logicielle et ses conséquences. Pour résumer ma pensée, une école/formation/entreprise où des débutants aident d'autres débutants à débuter dans la profession réduit fortement la montée en compétence de ces derniers et l’expression de leurs talents…

Former, accompagner et mentorer

Pour devenir un développeur ou une développeuse professionnelle, il y a trois axes essentielles:

• Être formé aux pratiques de développement :
  • la revue de code (oui, il y a des techniques et un savoir-être à acquérir),
  • le TDD / les tests automatisés,
  • le désendettement et les techniques de refactoring,
  • le "Clean Code".
• Être accompagné·e (via du pair/mob programming par exemple)
  • dans l'acquisition et l'ancrage des pratiques,
  • dans la montée en compétence technique (langage, framework, outil, architecture, …)
• Être mentoré·e (via des entretiens réguliers)
  • sur sa progression et sa carrière,
  • sur sa posture,
  • pour être aidé·e sur la résolution de problème.

D'un côté, si l’on suit les préceptes de Sandro Mancuso (cf. The Software Craftsman) ou Bob Martin (cf. Clean coder),  en tant que développeur ou développeuse, il est donc de notre responsabilité individuelle de trouver ou créer un environnement où les actions de ces 3 axes sont possibles. De l'autre, à l’opposé de la vision de ces auteurs, je trouve que c’est de la responsabilité de l’employeur d’être acteur de la progression de ses salariés et de créer les conditions de leur mise en place :

• En ayant des équipes hétérogènes (en terme de diversité, d'expérience et d'expertises).
• En complétant la formation initiale des développeurs et développeuses junior·es, notamment sur les pratiques.
• En valorisant le mentorat.
• En créant un environnement propice au pair programming, mob programming, à la demande d'aide, au feedback et au droit à l'erreur.
• En laissant la place à l’expérimentation et à l’erreur, pour mettre en pratique les méthodes vues en formation.

S'ouvrir au monde

Un moyen simple pour s’affranchir du vase clos et s'ouvrir aux influences extérieures : participer à des événements communautaires. Que ce soient des conférences, des meet ups ou des coding dojos, c'est l'occasion de faire connaissance avec ces nouvelles pratiques ou des nouvelles technologies. Cela peut même être l'occasion d'être initié  et accompagné dans une première phase d'apprentissage, notamment dans les coding dojos ou les conférences de type "Hands on".

Encore une fois, la responsabilité porte sur le développeur ou la développeuse mais aussi sur la société qui l'emploie. C’est un élément important de veille que de participer à ce genre d'événement. Il est judicieux que l'employeur (ou le client) donne l'opportunité à ses collaborateurs qui le souhaitent d’y aller (temps et moyens). Pour aller plus loin, il pourrait même s’engager à héberger dans ses locaux un événement communautaire ou encore de sponsoriser une conférence.

Les obstacles

Toutefois, si l'on se focalise sur les pratiques de développement notamment, la dure réalité des projets fait qu'il est souvent difficile d'appliquer par soi-même ce que l'on nous a expliqué en conférence. Même si, dans le meilleur des cas, la direction de projet nous permet de prendre le temps pour les mettre en place et que l'équipe est motivée pour se lancer, il est souvent difficile de s'y mettre une fois seul. Les causes les plus courantes que j'ai pu observer sont les suivantes :

• le code n’est pas adapté pour une mise en pratique immédiate des nouveaux savoirs (notamment pour le TDD et les tests unitaires automatisés).
• L'absence d'environnement dédié et/ou la complexité à créer un jeu de données (pour les tests d'intégrations).
• L'absence de tests automatisés (pour le refactoring et le clean code).
• L'absence d’organisation projet permettant d’institutionnaliser des pratiques (revues de code, pair programming) ou des rituels (gestion de la dette), comme ce que l’on peut voir dans les méthodes Agile et leurs outils (Kanban Board, Definition of Done, rétrospective).

La veille et ses limitations

La veille (vidéos, blogs, livre, papiers de recherche) est aussi une forme d’ouverture vers l'extérieur. Toutefois, j'ai pu rencontrer des équipes qui déclaraient faire de la veille et qui présentaient tout de même les symptômes du fonctionnement en vase clos. En effet, dans ces cas, la veille était soit trop superficielle, soit focalisée sur des points très techniques.  La veille très ciblée sur la technique peut renforcer l'opinion - consciente ou inconsciente - que le développement n'est qu'un savoir théorique.

De la prestation ?

Enfin, le recrutement en prestation de profils expérimentés peut être un bon moyen d’injecter des bonnes pratiques dans l’équipe. Mais encore faut-il pour cela qu’ils ou elles ne se fassent pas happer par la culture de l’équipe déjà en place. Dans ce genre de cas, j’ai pu observer malheureusement le départ anticipé des développeurs et des développeuses les plus aptes à faire sortir l’équipe du vase clos, ne restant que ceux qui adhèrent à la culture en place. Pour que cela fonctionne, il faut donc un mandat clair au prestataire, partagé par l’équipe en place : cette personne est là pour nous aider à progresser, prenons le temps d’écouter ce qu’elle a à nous proposer.

Sortir d’un vase clos

À ce stade, j’espère vous avoir donné les clés pour comprendre comment ne pas créer un environnement de consanguinité logicielle : former et accompagner les développeurs et développeuses juniors, mélanger les niveaux d'expertises, mettre en place du mentorat et inciter les équipes à participer à des événements communautaires. Que faire, par contre, si par un malheureux hasard, vous travaillez dans ou avec une équipe renfermée sur elle-même ?

Il faut d’abord commencer par un diagnostic externe, faire un état des lieux des douleurs. Ensuite, partager les résultats avec l'équipe, le management, la direction de projet (qu'on l'appelle Product Owner, Product Manager, Sponsor, chef de projet, MOA, CEO,…). S’il y a adhésion aux conclusions, d'un côté par les développeurs et développeuses à sortir du bricolage, de l'autre par la direction à l'importance de former des professionnels, vous pourrez envisager un plan d'action. Dans le pire des cas, c’est-à-dire une équipe ne connaissant aucune des pratiques de développement énoncées précédemment, il pourrait être de ce type :

• formation à la revue de code,
• formation aux tests automatisés et au TDD,
• formation au désendettement,
• formation aux principes du Clean Code,
• accompagnement de l'équipe sur ces 4 sujets sur plusieurs mois,
• accompagnement de la société sur la mise en place d'une culture de professionnalisation du développement :
  • parcours de carrière,
  • formation,
  • proposition de participation à des conférences,
  • mise en place de mentorat.

Dans le cadre d'une équipe de prestataires, il arrive que  le client impose ce genre de formation à ses fournisseurs ainsi qu'une partie de l'accompagnement.

Face au diagnostic d'un logiciel possédant les tares décrites au début de cet article, la fausse bonne idée serait de faire une refonte car l'équipe aura beau être plus expérimentée, sans apprentissage des pratiques de développement, elle continuera à reproduire le même génome …