Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    Le mythe du mois-homme : un développeur écrit en moyenne 10 lignes de code logique par jour ?
    Que vaut le mythique mois-homme de la Bible du génie logiciel qui suggère qu'un dev écrit en moyenne 10 lignes de code logique par jour,
    face à des statistiques de 14 ans de développement à 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 ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre éclairé
    "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...

  3. #3
    Membre habitué
    Construire une réflexion est parfois plus long que la formaliser.

  4. #4
    Membre actif
    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.

  5. #5
    Expert éminent sénior
    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 ?
    La théorie, c'est quand on sait tout et que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
    ( A Einstein)

  6. #6
    Membre éclairé
    L ' ouvrage reste pour moi pertinent , malgré nos systèmes de luxe , nos langages objets , nos tests de fonctionnalité / sécurité etc

  7. #7
    Membre averti
    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.

  8. #8
    Membre éclairé
    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

    euh parle de t-on de personnes comme Emmanuel Kant et sa critique de la Raison Pure ?
    Parfaitement d'accord, en revanche sur un projet perso je passe 5 fois plus de temps avant de me lancer parce-que je sais pas exactement ce que je vais faire

  9. #9
    Membre actif
    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 ?
    Parlons peu, mais parlons bien.

  10. #10
    Membre éclairé
    J'aimerais tellement faire 10 lignes de code par jour en ce moment. Je fais plus que de l'analyse et des extracts.

  11. #11
    Membre éclairé
    J'écris 500 lignes de code par jour. Je ne suis donc pas employable comme développeur. Heureusement ce n'est finalement pas mon métier.
    Sur Youtube je suis "Le développeur des cavernes"
    https://www.youtube.com/channel/UCSz...bYl_pSNMv_zerQ

  12. #12
    Membre habitué
    bon article, plutot réaliste !
    …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.

  13. #13
    Invité
    Invité(e)
    La plupart des gros logiciels connus font plusieurs millions de lignes de code. A croire qu'ils se sont écris tout seuls.
    A un moment donné il faut bien coder, ce qui veut dire aligner des lignes de codes.

  14. #14
    Membre régulier
    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.

  15. #15
    Invité
    Invité(e)
    Citation Envoyé par cecedu26 Voir le message
    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.
    Intéressante votre histoire. Ca rend humble.

  16. #16
    Expert éminent sénior
    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...
    - So.... what exactly is preventing us from doing this?
    - Geometry.
    - Just ignore it !!
    ****
    "The longer he lived, the more he realized that nothing was simple and little was true" A clash of Kings, George R. R. Martin.
    ***
    Quand arrivera l'apocalypse, il restera deux types d'entreprise : les pompes funèbres et les cabinets d'audit. - zecreator, 21/05/2019

  17. #17
    Membre éprouvé
    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).

  18. #18
    Membre éclairé
    Citation Envoyé par Ekolamar Voir le message
    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).
    Je pense pas que c'est forcement que les gens n'y comprennent rien, je pense que chacun à une vision différente de ce qu'il veut pour le produite, et sans ligne directrice claire ça devient vite le bordel avec des MEP faites à la vas-vite et des demandes faites sur le coin d'un post-it.

  19. #19
    Membre éprouvé
    Citation Envoyé par L33tige Voir le message
    Je pense pas que c'est forcement que les gens n'y comprennent rien, je pense que chacun à une vision différente de ce qu'il veut pour le produite, et sans ligne directrice claire ça devient vite le bordel avec des MEP faites à la vas-vite et des demandes faites sur le coin d'un post-it.
    Non, c'est la conséquence que personne ne comprend/respect ce qu'est un projet et un périmètre projet.

    C'est pour ça qu'on a inventé la "méthode agile", c'est pour accommoder les gens qui changent tout le temps d'avis et ne savent pas se décider en leur disant qu'on prendra en compte leur remarque toutes les 1-2 semaines (sprint) plutôt que "jamais" dans un projet en waterfall comme ça devrait être la norme.

    Personne n'accepte qu'on l'envoie bouler (à juste titre, fallait qu'ils se réveillent avant le lancement du projet, pendant la phase d'expression de besoin), donc on force des modifications dans tous les sens sur des projets en cours qui se plantent de façon totalement évidente (dépassement de budget, de délai, qualité déplorable etc.).

  20. #20
    Expert éminent
    Ekolamar tu résumes parfaitement bien la situation, bravo pour ce post qui sur ce sujet fait office de référence !

###raw>template_hook.ano_emploi###