Les ciseaux plutôt que les euros

Sur nos projets, on voudrait aller plus vite. Et deux options arrivent naturellement dans la discussion :

en faire moins, c’est-à-dire réduire le périmètre des fonctionnalités,
renforcer les effectifs.

J’ai remarqué combien les développeurs sont réticents face à la seconde solution.

On n’imagine pas qu’un renfort (même conséquent) permettra réellement d’accélérer. Et à un moment de la discussion, surgit cette citation célèbre.

9 femmes ne font pas un bébé en 1 mois.

J’avoue avoir aussi eu recours à cette formule tout faîte. Mais qu’exprime-t-elle profondément ?

Qu’est-ce qui rend un renfort inutile (ou carrément contre-productif) sur un projet de développement logiciel ?

Alors bien sûr, il y a l’appropriation du contexte métier, de l’organisation du code. S’acculturer au vocabulaire, aux pratiques de développement. Autant de barrières à l’entrée pour un nouveau venu.

Mais ce n’est pas toujours la vraie raison.

La vraie raison, c’est qu’on ne parvient pas à paralléliser le travail.

C’est le sens de la citation.

La gestation ne peut pas être découpée en plusieurs tâches indépendantes, que l’on pourra réaliser simultanément. Il faut attendre que le foetus ait atteint 3 mois pour faire le boulot du 4e mois.

En d’autres termes, il y a du couplage temporel. Un ordre à respecter.

Dans la méthodologie de projet, on appelle ça le chemin critique. C’est l’enchaînement optimal des tâches qui doivent être réalisées successivement.

Mais il n’y a pas que ça.

Couplage temporel = couplage fonctionnel

Parfois, le chemin critique bouge. Un truc dont on n’avait pas parlé surgit comme un point bloquant.

“Mais pourquoi n’aviez-vous pas anticipé ça ?”

Parce que le logiciel sur lequel on travail est complexe, et qu’on n’en connaît pas tout les détails.

Avec le recul, j’observe que les projets IT qui rencontrent le moins de difficultés à respecter les échéances sont ceux qui impliquent peu de développeurs. Parfois même un seul !

Mais dès que l’équipe dépasse 4 ou 5 personnes, ça devient lent. On attribut à Jeff Bezos la règle des 2 pizzas (”We try to create teams that are no larger than can be fed by two pizzas”).

Une étude comparative portant sur 4000 projets informatiques (référence en fin d’article) s’est intéressée à la durée nécessaire pour produire 100,000 lignes de code.

En moyenne, il fallait 40 semaines pour y parvenir.

Mais le plus surprenant, c’est la faible influence du nombre de personnes : les équipes de 5 personnes ou moins ont mis 1 semaine de plus qu’une équipe de 20 personnes.

4 fois plus de monde, pour un gain de 2.5% ! (et en bonus, 5 fois + de bugs indique l'étude !)

Voila qui devrait faire réfléchir avant de quadrupler les effectifs et les coûts.

Pourquoi si peu de gain ?

A cause du couplage dans le code.

Dans la majorité des projets, on doit se coordonner. Communiquer. Orchestrer. On bosse ensemble. On est une équipe. On s’aime tous ♥️.

Traduire : on s’attend.

Pardon de casser l’ambiance.

Mais pour travailler à plusieurs sur un même projet sans devenir une usine à bullshit, il n’y a qu’une seule méthode. Inventée par l’industrie automobile il y a un siècle .

La modularité

La modularité consiste à découper un projet en parties indépendantes les unes des autres, afin de pouvoir paralléliser le travail.

Entendons-nous sur cette notion d’indépendance pour un logiciel : il faut qu’une équipe puisse mettre en production une nouvelle fonctionnalité sans besoin d’interagir avec d’autres équipes.

Pour y parvenir, il faut faire du rangement.

(parfois pompeusement nommé “architecture”).

Par exemple en organisant son code par domaine métier. Celui qui bosse sur une nouvelle fonctionnalité de facturation n’interfère pas avec celui qui bosse sur le catalogue des produits.

Alors évidemment, il y a des points de contact entre les domaines métiers : les interfaces. Chaque langage typé possède sa manière de les coder.

Ce sont des contrats qu’un domaine passe avec les autres. Des portes d’entrées et de sorties. Ca vaut la peine d’y mettre un peu de réflexion pour qu’elles soient stables : elles posent les contours des modules, et conditionnent la capacité de travailler à plusieurs.

Le bonus, c’est la réduction de la complexité. Lorsque les domaines sont indépendants, petits, bien séparés les uns des autres, alors une équipe réduite (et même 1 seule personne) parvient à acquérir la compréhension détaillée sur SON domaine, sans besoin de connaître celui des autres.

Bien sûr, l'équipe de dev peut (doit) communiquer sur ce qu’elle fait. On n'est pas des geeks introvertis avec des chaussures de montagnes incapables de parler avec les autres.

Mais avec du code modulaire, on avance vite sans être bloqué par personne.