Que vaut le mythe du mois-homme de la Bible du génie logiciel suggérant qu'un dev écrit en moyenne 10 lignes de code logique par jour

Face à des statistiques de 14 ans de dev à temps plein ?

The Mythical Man-Month: Essays on Software Engineering est un livre sur le génie logiciel et la gestion de projet de Fred Brooks publié pour la première fois en 1975, avec des éditions ultérieures en 1982 et 1995. Son thème central est que « l'ajout de main-d'œuvre à un projet logiciel déjà en retard sur sa feuille de route fait qu'il sera livré encore plus tard ».

Les observations de Brooks sont basées sur ses expériences chez IBM lors de la gestion du développement d'OS/360. Il avait ajouté plus de développeurs à un projet en retard, une décision qu'il qualifiera plus tard de contre-intuitive étant donné qu'elle a retardé encore plus le projet. Il a également fait l'erreur d'affirmer qu'un projet (impliqué dans la rédaction d'un compilateur ALGOL) nécessiterait six mois, quel que soit le nombre de travailleurs impliqués (il fallait plus de temps). La tendance des managers à répéter de telles erreurs dans le développement du projet a conduit Brooks à rire du fait que son livre s'appelle « La Bible du génie logiciel » mais que « tout le monde le cite, certaines personnes le lisent et quelques personnes le suivent ». Le livre est largement considéré comme un classique des éléments humains du génie logiciel.

Le mythique mois-homme

Brooks discute de plusieurs causes d'échecs de planification. Celle dont il parle le plus dans ses observations (appelées aussi lois de Brooks) est que « l'ajout de main-d'œuvre à un projet logiciel déjà en retard sur sa feuille de route fait qu'il sera livré encore plus tard ». Le mois-homme est une unité de travail hypothétique représentant le travail effectué par une personne en un mois ; la loi de Brooks dit que la possibilité de mesurer le travail utile en mois-hommes est un mythe.

Les projets de programmation complexes ne peuvent pas être parfaitement divisés en tâches discrètes qui peuvent être travaillées sans communication entre les travailleurs et sans établir un ensemble d'interrelations complexes entre les tâches et les travailleurs qui les exécutent.

Par conséquent, affecter plus de programmeurs à un projet en retard sur le calendrier le fera prendre encore plus de retard. En effet, le temps nécessaire aux nouveaux développeurs pour en savoir plus sur le projet et l'augmentation des temps de communication consommera une quantité toujours croissante du temps de calendrier disponible. Lorsque n personnes doivent communiquer entre elles, lorsque n augmente, leur production diminue et lorsque n devient négatif, le projet est encore retardé avec chaque personne ajoutée.

Le mythique mois-homme : un développeur peut écrire en moyenne 10 lignes de code logique par jour

Patrick Smacchia est un ingénieur logiciel qui s'est également intéressé à ce livre. Dans un billet,il a paraphrasé le mythique mois-homme, indiquant que « quel que soit le langage de programmation choisi, un développeur professionnel écrira en moyenne 10 lignes de code (LdC) par jour ».

Fort de ses 14 ans d'expérience dans le développement à plein temps sur l'outil NDepend, il a voulu développer un peu.

« Commençons par la définition de la ligne de code logique. Fondamentalement, un LdC logique est un point de séquence PDB à l'exception des points de séquence correspondant à l'accolade de méthode d'ouverture et de fermeture. Nous avons donc ici une méthode de 5 lignes logiques de code par exemple:


« J'entends déjà des lecteurs se plaindre qu'une LdC n'a rien à voir avec la productivité. D'ailleurs Bill Gates a dit un jour : "mesurer la productivité d'un logiciel par des lignes de code, c'est comme mesurer la progression d'un avion par son poids".

« Et en effet, mesurée sur quelques jours ou quelques semaines, la LdC n'a rien à voir avec la productivité. En tant que développeur à temps plein, certains jours, j'écris 200 LdC d'affilée, d'autres jours je passe 8 heures à corriger un bogue embêtant en n'ajoutant même pas de LdC. Un jour, je vais à la chasse au code mort et supprime des LdC. Des fois, il m'arrive de refactoriser le code existant sans, dans l'ensemble, ajouter une seule LdC. D'autres jours, je crée un contrôle d'interface utilisateur grand et complexe et l'éditeur génère automatiquement 300 LdC supplémentaires. Certains jours sont dédiés uniquement à l'amélioration des performances ou à l'écriture de tests, etc.

« Ce qui est intéressant, c'est le nombre moyen de LdC obtenu à long terme. Et si je fais le calcul simple, notre moyenne est d'environ 80 LdC par jour. Précisons que nous sommes stricts sur la norme de qualité élevée du code, tant en termes de structure et de formatage du code qu'en termes de test et de taux de couverture du code. Pour un outil de qualité de code pour les développeurs, être strict sur la qualité du code implique faire du dogfooding.

« Donc, ce score moyen de 80 LdC produit par jour ne sacrifie pas la qualité du code et représente un rythme qui peut tenir sur la durée. Les choses deviennent intéressantes avec LoC après l'étalonnage: se soucier du comptage de LdC devient un outil d'estimation précis. Après avoir codé et mesuré des dizaines de caractéristiques obtenues dans ce contexte particulier de développement, la taille de toute caractéristique peut être estimée avec précision en termes de LdC. Par conséquent, avec des calculs simples, le temps qu'il faudra pour mettre une fonctionnalité en production peut être estimé avec précision. Pour illustrer ce fait, voici une vue arborescente décorée de la base de code NDepend, K signifie 1000 LdC.


« Grâce à cette carte, je peux comparer la taille en termes de LdC de la plupart des composants. En combinant ces informations avec le fait que le score de codage moyen est de 80 LdC par jour, et en regardant en arrière le coût en temps pour chaque composant, nous avons une méthode précise pour ajuster notre façon de coder et d'estimer les calendriers futurs.

« Bien sûr, tous les composants ne sont pas égaux. La plupart d'entre eux sont le résultat d'un long processus de codage évolutif. Par exemple, le modèle de code avait subi beaucoup plus de refactorisation depuis le début que, disons, la matrice de dépendance par exemple qui avait été livrée prête à l'emploi après quelques mois de développement.

« Cette carte révèle autre chose d'intéressant. Nous pouvons voir que toutes ces années ont passé à polir l'outil pour répondre à des normes professionnelles élevées en termes d'ergonomie et de performances, consommant en fait pas mal de LdC. Évidemment, la construction d'un moteur de requête de code performant basé sur C# LINQ qui est maintenant l'épine dorsale du produit a pris des années. Cette fonction à elle seule pèse désormais 34 K LdC. Plus surprenant, il suffit d'avoir une gestion de l'interface utilisateur des propriétés du projet et des prises de modèle propres (modèle + interface utilisateur) = (4K + 7K) = 11K LdC. Bien qu'une fonctionnalité phare telle que le graphique de dépendance interactif ne consomme que 8 K LdC, pas autant que la mise en œuvre des propriétés du projet. Bien sûr, le graphique de dépendance interactif capitalise beaucoup sur l'infrastructure existante développée pour d'autres fonctionnalités, notamment le modèle de dépendance. Mais en fait, il a fallu autant d'efforts pour développer le graphique de dépendance que pour développer un modèle de propriétés de projet et une interface utilisateur raffinés.

« Tout cela confirme une leçon essentielle pour toute personne en charge d'un Éditeur de logiciel. Il est léger et facile à développer une application prototype agréable et flashy qui apportera des utilisateurs passionnés. Ce qui est vraiment coûteux, c'est de le transformer en quelque chose d'utile, de stable, de propre, de rapide avec tous les bonbons ergonomiques possibles pour faciliter la vie de l'utilisateur. Et ce sont toutes ces exigences non fonctionnelles qui feront la différence entre un produit utilisé par quelques dizaines d'utilisateurs passionnés uniquement, et un produit utilisé par la masse ».

Source : NDepend, Mythical man-month

Et vous ?

Qu'en pensez-vous ?
Que pensez-vous de la loi Brook qui suggère que « l'ajout de main-d'œuvre à un projet logiciel déjà en retard sur sa feuille de route fait qu'il sera livré encore plus tard » ?
Que pensez-vous de la partie du mythe du mois-homme qui suggère qu'un développeur peut écrire en moyenne 10 lignes de code logique par jour ?
Vous retrouvez-vous dans cette catégorie ?
Quelle lecture faites-vous des statistiques apportées par NDepend ?
Vient-elle infirmer ou affirmer l'observation du mois-homme sur les lignes de code logique ?
Partagez-vous l'avis du développeur NDepend qui affirme qu'en combinant ces informations avec le fait que le score de codage moyen est de 80 LdC par jour, et en regardant en arrière le coût en temps pour chaque composant, son équipe dispose d'une méthode précise pour ajuster la façon de coder et d'estimer les calendriers futurs ?