Cela dépend du projet. En moyenne (toujours pas vraiment précis), un nouveau projet se situera entre 0 et 10 000 (en fonction surtout de si vous êtes dans la phase d'architecture ou de construction initiale) tandis qu'un très vieux projet sera n'importe où entre négatif (par l'optimisation, le refactoring) et 0 (en essayant de fouiller et de trouver ce qui se passe pour éviter de casser quoi que ce soit quand vous allez faire le changement) à peut-être quelques centaines (en ajoutant une nouvelle fonctionnalité après avoir beaucoup fouillé pour s'assurer que rien ne se cassera en l'ajoutant.)
Les métiers de la programmation sont notoirement difficiles à mettre des mesures standardisées d'à peu près n'importe quel type (bien que la notation big-O aide un peu à cet effort d'un point de vue purement technique de performance du code pour le matériel disponible) car vous essayez de quantifier quelque chose qui est lui-même en train d'essayer de quantifier quelque chose d'une manière abstraite - en demandant " combien de lignes de bon code seraient raisonnables ?", vous demandez essentiellement de construire un système complet de Turing pour décrire un autre système, pour chaque scénario possible dans lequel il est demandé.
Les personnes ayant beaucoup d'expérience dans le développement de logiciels seront généralement en mesure de frapper l'estimation d'un projet à moins de 20% s'ils font une bonne quantité de recherche au préalable et connaissent à fond tous les aspects des systèmes impliqués, mais cela inclura généralement aussi un facteur de truquage assez important parce que la seule chose que l'expérience enseigne vraiment à cet égard est de supposer que vous le sous-estimez (sur des milliers, je n'ai pas encore rencontré de développeur qui n'ait pas surestimé sa capacité à pomper du code - typiquement parce que tout le monde suppose l'ensemble du projet dans un état de "flux" lors de l'estimation, des développeurs aux clients, mais arriver à cet état d'esprit lui-même tend à impliquer une portion de temps assez importante et s'articule autour de nombreux facteurs environnementaux.)
Pour en donner un exemple extrême : J'ai travaillé une fois pour un entrepreneur qui écrivait des logiciels d'entreprise lorsque je commençais dans l'industrie, après quelques mois, j'avais ce que je pensais être une saisie décente de la durée d'un projet similaire. Je l'ai estimé, en supposant qu'il se déroulerait à peu près comme le précédent (ils étaient presque identiques, en fait il s'agissait de la version 2 du projet précédent qui était réécrite de A à Z pour faciliter de nouvelles fonctionnalités). Tout allait bien pendant la phase d'architecture, puis un temple hindou a loué l'unité d'à côté et toutes les 10-30 minutes, pendant quelques minutes à la fois, tous les jours, quelqu'un sonnait une cloche de vache, il y avait une discussion sur la façon dont la cloche de vache était ennuyeuse, il y avait une discussion de gestion sur un nouvel emplacement à déménager, il y avait des discussions secondaires sur les discussions de gestion demandant aux gens de contribuer à de nouveaux emplacements et plans d'étage, etc. Un mois s'écoule et pratiquement aucun progrès n'a été fait, au point que j'ai dû commencer à travailler à la maison parce que j'étais incapable de me concentrer plus de 10 minutes à la fois sans être interrompu, j'étais à la fois paniqué à l'idée que j'allais être licencié et choqué que personne n'en ait parlé. Un autre mois (cette fois-ci de travail productif) avec peu de mises à jour visibles pour le client et ils ont décidé de commencer avec le scope creep, supposant probablement qu'il n'y avait rien de majeur à changer - ce qui a conduit à jeter d'énormes segments de code existants, à en réviser d'autres, à en ajouter de nouveaux à l'architecture, etc. Deux mois et demi plus tard, je termine le projet (principalement de la maison, en venant juste pour des jours avec des réunions) et je demande comment mon patron ne paniquait pas à propos du projet qui prenait tant de retard - il s'avère que ses décennies d'expérience dans le logiciel lui ont appris à multiplier par 4 les estimations données par les développeurs.
Plus d'une décennie d'expérience dans l'industrie plus tard et j'ai appris la morale de cette histoire : il y aura toujours une cloche à vache. Vous ne pouvez pas estimer en vous basant sur votre pic ni supposer qu'il n'y aura pas de recherche, de planification, de réunions, etc. impliquées dans un projet qui détournent le temps passé à écrire du code. À son tour, mesurer le code par le nombre de lignes écrites est en fait un peu comme essayer de négocier des actions sur des informations purement techniques : cela pourrait fonctionner, jusqu'à ce qu'à peu près n'importe quel événement se produise et que tous vos marqueurs techniques ne signifient rien.