IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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 ?

Le , par Stéphane le calme

494PARTAGES

22  0 
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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de fodger
Membre confirmé https://www.developpez.com
Le 12/02/2020 à 14:13
Construire une réflexion est parfois plus long que la formaliser.
15  0 
Avatar de Mat.M
Expert éminent sénior https://www.developpez.com
Le 12/02/2020 à 22:22
Citation Envoyé par Stéphane le calme Voir le message
Que pensez-vous de la partie du mythique mois-homme qui suggère qu'un développeur peut écrire en moyenne 10 lignes ce code logique par jour
je ne sais pas chez vous mais moi j'ai l'impression d'être 5 fois plus productif sur un projet personnel en faisant du code que sur un projet en entreprise.
(J'ai failli crée un fil de discussion là-dessus).

Ce qui se passe c'est lorsqu'on est tout seul à travailler sur un projet on sait quasiment ce que l'on veut, dans quelle direction aller, contrairement à un projet en entreprise où il y a plusieurs échelons de décision.
Bref la morale de cette histoire c'est que plus une équipe de développement est réduite à mon sens plus le projet sera fonctionnel et plus on sera efficace

Citation Envoyé par fodger Voir le message
Construire une réflexion est parfois plus long que la formaliser.
euh parle de t-on de personnes comme Emmanuel Kant et sa critique de la Raison Pure ?
12  1 
Avatar de Glutinus
Inactif https://www.developpez.com
Le 19/02/2020 à 10:05
Bossant pour les grandes entreprises, 10 lignes de code, c'est 100 lignes de formulaire pour faire livrer, 1000 lignes de mail d'engueulade avec la MOA et 10.000 lignes de PowerPoint pour alimenter la petite guéguerre politique entre internes...
11  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 26/02/2020 à 11:28
Citation Envoyé par Glutinus Voir le message
Bossant pour les grandes entreprises, 10 lignes de code, c'est 100 lignes de formulaire pour faire livrer, 1000 lignes de mail d'engueulade avec la MOA et 10.000 lignes de PowerPoint pour alimenter la petite guéguerre politique entre internes...
J'ai déjà cité cet exemple, mais dans une banque Française, Nous cobolistes étions deux fois plus productifs que les javaistes. Nous n'étions pas meilleurs, et notre langage pas meilleur(enfin, pas à ce point là, et de très loin). Mais quand on avait une modif à faire, on pouvait la livrer en prod en 4 minutes chrono. Pour des raisons de contrôle des livrables, les gens du JAVA, eux, passaient par un process à se flinguer. Il y avait même une "cellule d'intégration" dont le seul rôle était de faire les livraisons.

Résultat? Il n'y avait pas plus de bugs à la livraison en cobol qu'en java. Tout ce bousin ne servait strictement à rien. D'autant plus que si bug à la livraison il y avait en cobol, on pouvait livrer le correctif en 4 minutes.....Conclusion logique : ils parlaient de mettre en place les cellules d'intégration pour le cobol. (enfin, logique pour les chefs qui avaient besoin de justifier leur existence, hein). Je suis parti avant de me prendre ça sur la tronche.
9  0 
Avatar de Ekolamar
Membre éprouvé https://www.developpez.com
Le 19/02/2020 à 22:57
Citation Envoyé par Glutinus Voir le message
Bossant pour les grandes entreprises, 10 lignes de code, c'est 100 lignes de formulaire pour faire livrer, 1000 lignes de mail d'engueulade avec la MOA et 10.000 lignes de PowerPoint pour alimenter la petite guéguerre politique entre internes...
This

Et c'est pas spécifique au développement. En (grande) entreprise, on passe 9/10ème de son temps à défendre sa façon de faire que faire à sa façon, avec des procédures qui prennent souvent littéralement des semaines.

Pourquoi ce sont les PME qui sortent les logiciels et idées innovantes ? Vous pensez que c'est par parce que personne ne les as eu avant ? Non, c'est juste que les gars ils peuvent bosser et adapter leurs idées comme ils veulent en PME (enfin, quand le PDG sait faire confiance)

Pourquoi le logiciel super tip-top au poils de la PME il devient tout pourri dès qu'il est racheté ? Parce que plein de personnes qui n'y comprennent rien ne peuvent s'empêcher de donner leur avis (que les développeurs sont obligés de suivre, souvent c'est les managers).
8  0 
Avatar de VBurel
Membre averti https://www.developpez.com
Le 15/02/2020 à 8:41
…qui se résume par l'adage: 9 femmes enceintes ne feront pas un enfant en 1 mois.

Ceci dit, même dans cet article, en matière de productivité, temps de développement, on ne tient toujours pas compte de l'expérience des personnels, notamment celle qui concerne l'industrialisation (10 lignes de code écrites avec ou sans expérience, c'est pas la même chose). Et comme l'expérience n'est pas valorisée, il y a très peu d'ingénieur (ou de département R&D, développement) qui capitalisent sur cette expérience d'industrialisation.

Cette manière de mépriser les savoirs faire industriels, et plus généralement tous les métiers de production, fait que la France et l’Europe ont perdu pied en matière d’IT… et la tendance s’intensifie aujourd'hui puisque les organisations de travail fabriquent et embauchent essentiellement des cadres, qui comme leur nom l’indique, ne produisent rien.

Ce que je veux dire par là, c'est qu'il faudrait peut être ré-écrire le bouquin aujourd'hui en tenant compte de la nouvelle façon de gérer les projets en 2020: par obligation de moyens et ignorance des objectifs (et rien a foutre des personnels productifs)... alors qu'en 1995 c'était différent.
7  0 
Avatar de gallima
Membre averti https://www.developpez.com
Le 12/02/2020 à 20:57
Citation Envoyé par fodger Voir le message
Construire une réflexion est parfois plus long que la formaliser.
Et parfois formaliser aide à construire la réflexion.
6  0 
Avatar de L33tige
Membre expérimenté https://www.developpez.com
Le 12/02/2020 à 13:31
"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"

Je suis vraiment pas certain que ça soit vrai, quand on vois le nombre d'ELT's, ou même de logiciels de façon plus générale qui sont juste utilisés à cause du monopole, des licences, de l'habitude, ou du fonctionnel pur...
5  0 
Avatar de cecedu26
Membre régulier https://www.developpez.com
Le 17/02/2020 à 23:29
Un jour je lance un defi a un collegue qui devait coder une page html+js dans la journee (truc de base, rien de compliqué).
En mee temps il y avait un gars a l'exterieur du batiment qui devait nettoyer de grandes baies vitrees sur 200m (a la perche).
Je lui dis on fait le point de qui a finit son boulot en milieu de journee ?

Devinez qui a gagné ?
La page de code n'a pas pu etre finie au bout de la premiere journee mais fut terminée le jour suivant. 2j vs 1/2 journee. Ou il a pris conscience qu'on fait un boulot ou on enc... quelques fois les mouches.
5  0 
Avatar de Emmanuel R
Membre averti https://www.developpez.com
Le 13/02/2020 à 11:24
Citation Envoyé par Mat.M Voir le message
je ne sais pas chez vous mais moi j'ai l'impression d'être 5 fois plus productif sur un projet personnel en faisant du code que sur un projet en entreprise.
(J'ai failli crée un fil de discussion là-dessus).

Ce qui se passe c'est lorsqu'on est tout seul à travailler sur un projet on sait quasiment ce que l'on veut, dans quelle direction aller, contrairement à un projet en entreprise où il y a plusieurs échelons de décision.

Bref la morale de cette histoire c'est que plus une équipe de développement est réduite à mon sens plus le projet sera fonctionnel et plus on sera efficace
Même ressenti sur la productivité sur les projets personnels.
Je rajouterais qu'elle est boostée de part l’expérience qu'on peut avoir sur le terrain, l'inspiration de nos collègues, ou encore de la stack en place. Et elle est d'autant plus boostée que l'on travaille pour nous.

Sur la partie des "plusieurs échelons des décisions", je suis plus nuancé, même si je suis d'accord sur le fond.

Je pense qu'avec une vraie équipe impliquée sur le projet, autant côté métier que tech, et chacun fort de son organisation personnelle, les échelons comptent moins. Chacun doit pouvoir trouver un moment pour se retrouver et faire avancer les choses, même si le temps se plus rare au fil des échelons. Encore une fois, cela suppose que l'on travaille dans un environnement entre individus impliqués - et rationnels -. Ce qui est loin d'être tout le temps le cas. Et c'est plus facile avec une équipe réduite, je rejoins ta morale .

Ici, il m'est clair que dans un projet classique, l'on est davantage bloqué par l'humain et le manque de rationalisation. Les petites politiques, les jeux internes de positionnement, l'opacité, les intérêts personnels (carrière, plaire au chef), les jeux de dupes, la gestion des susceptibilités ("oui mais machin ne va pas être là on en a absolument besoin pour notre réu " (oui mais en fait non)), et même tout simplement des mauvaises interactions humaines car le savoir-être de la personne en face n'est pas apprécié et que l'envie d'échanger diminue voire disparaît...

Voilà ce qui freine la productivité, davantage qu'un nombre de lignes de codes peu élevé.

Mais bon, hein. C'est un KPI qui n'est pas mesurable et qui demande une certaine introspection de chacun. Donc ça continue à faire l'objet de posts inspirants sur LinkedIn, et on continue à mesurer du quantitatif sur lequel on peut avoir de la data. C'est plus facile.
4  0