- En 2007, 2 000 lignes de code

The Original Macintosh: 36 of 123 - 2000 Lines Of Code

• Au début de 1982, l’équipe logicielle de Lisa se concentrait sur les dernières étapes du travail afin de livrer le logiciel dans les six mois à venir.

• Certains responsables ont pensé que ce serait une bonne idée de suivre chaque semaine la quantité de code écrite par chaque ingénieur, et ont créé un formulaire à remettre chaque vendredi, avec un champ indiquant le nombre de lignes de code écrites cette semaine-là.

• Bill Atkinson, auteur de Quickdraw et principal concepteur de l’interface utilisateur, estimait que le nombre de lignes de code était une manière absurde de mesurer la productivité logicielle, car cela ne faisait qu’encourager l’écriture d’un code désordonné, gonflé et bogué.

• Atkinson travaillait récemment à l’optimisation du moteur de calcul de régions de Quickdraw, et a entièrement réécrit le moteur de régions à l’aide d’un algorithme plus simple et plus général, ce qui, après quelques ajustements, a rendu les opérations sur les régions presque 6 fois plus rapides.

• Cette réécriture a eu pour effet secondaire d’économiser environ 2 000 lignes de code.

• Lors de la phase finale de cette optimisation, il a dû remplir pour la première fois le formulaire de gestion et, arrivé à la section sur le nombre de lignes de code, il a réfléchi un instant puis a inscrit le nombre -2000.

• On ne sait pas exactement comment les responsables ont réagi, mais quelques semaines plus tard, ils ont cessé de demander à Atkinson de remplir le formulaire, ce à quoi il s’est volontiers conformé.

L’avis de GN⁺

• Cet article transmet une leçon importante : dans le développement logiciel, la quantité de code n’est pas un véritable indicateur de productivité. Mesurer la performance au nombre de lignes de code est non seulement inefficace, mais peut parfois produire l’effet inverse.
• L’exemple de Bill Atkinson souligne l’importance de l’optimisation logicielle. Obtenir de meilleures performances avec moins de code est l’un des principes fondamentaux du software engineering.
• Cette histoire aide à comprendre pourquoi les pratiques de développement modernes, notamment les méthodologies agiles et les approches comme l’intégration et le déploiement continus (CI/CD), sont importantes. Ces méthodologies accordent plus de valeur à la qualité, à la maintenabilité et à l’expérience utilisateur qu’à la quantité de code.
• Dans l’industrie, divers outils et métriques sont utilisés pour mesurer et améliorer la qualité du code, par exemple les outils d’analyse statique, les processus de code review et le suivi de la couverture de tests.
• Cet article rappelle aux développeurs combien il est important de se concentrer sur la qualité plutôt que sur la quantité de code, d’éviter la complexité inutile et d’optimiser les performances.

[GN⁺]

Avis Hacker News

• Conflit autour du nombre de lignes de code entre Microsoft et IBM

  • Dans la série TV de PBS "Accidental Empires", une scène montre Steve Ballmer racontant son expérience à l’époque du co-développement d’OS/2. Microsoft travaillait avec l’état d’esprit d’une petite entreprise, tandis qu’IBM se concentrait en interne sur le nombre de lignes de code (en milliers de lignes, KLoC) comme indicateur de productivité des programmeurs. Ballmer reprochait à IBM de ne s’intéresser qu’à la quantité de code, et non à sa qualité.

• Liens vers des discussions précédentes

  • Les débats sur l’utilisation du nombre de lignes de code comme indicateur de productivité reviennent souvent. Des liens sont fournis pour montrer diverses discussions entre 2010 et 2022.

• Utiliser le nombre de lignes de code comme indicateur de production est profondément absurde

  • Un intervenant évoque avoir corrigé un bug vieux de 20 ans avec une seule ligne de code, ou un bug vieux de 3 ans avec un simple order by, et s’interroge sur la manière de mesurer l’impact d’une seule ligne. Il partage aussi son expérience selon laquelle les mauvais programmeurs écrivent davantage de code, et cite un cas où un développeur Microsoft a réécrit 33 000 caractères de code IBM en 220 caractères. Cela aurait conduit à considérer le travail de Microsoft comme « négatif ».

• Une question simple a parfois le plus grand impact

  • Une question aussi simple que « Comment va-t-on gérer X ? » peut mener à la décision de ne pas développer une fonctionnalité, ce qui permet d’économiser tous les coûts liés à sa tentative de mise en œuvre. Ce type de contribution ne se mesure pas en chiffres et peut parfois se faire des ennemis, mais l’auteur rend malgré tout hommage à ceux qui osent le faire.

• Partage d’une expérience d’optimisation de code en début de carrière

  • Un intervenant raconte avoir optimisé un programme en C de plus de 10 000 lignes pour le ramener à moins de 500. Il a découvert que le développeur précédent avait simplement réécrit en inline les mêmes instructions SQL de façon répétée, probablement parce qu’il ne savait pas utiliser des fonctions ni transmettre des données variables à des requêtes SQL. Le code dupliqué a été remplacé en réécrivant les appels SQL sous forme de fonctions, puis en appelant ces fonctions dans une boucle avec des valeurs de bind modifiées récupérées depuis un tableau.

• Le manque de direction claire au démarrage d’un projet

  • Il arrive qu’au lancement d’un projet on ne sache pas exactement dans quelle direction aller ; en s’immergeant dans le projet, on comprend mieux le problème et la réponse souhaitée, ce qui permet ensuite de retirer de grosses portions du code pour les remplacer par quelque chose de plus petit et de meilleur. Les développeurs qui devaient tout faire tenir dans 64 KB de ROM subissaient une forte pression pour réduire la taille du code.

• Expérience de pensée sur l’idée de mesurer les suppressions de code

  • Un intervenant propose une expérience de pensée : si un manager lit cet article et décide naïvement d’utiliser le nombre de lignes de code supprimées comme indicateur, la situation s’améliorerait-elle ou empirerait-elle ?

• Bill Atkinson et l’Atkinson Dither

  • Un lien est fourni à propos de Bill Atkinson et de sa technique Atkinson Dither.

• Perception du nombre de lignes de code

  • Un intervenant remet en question l’idée d’utiliser « lignes ajoutées - lignes supprimées » lors de l’écriture de code. De la même manière qu’une course de 10 km qui commence et se termine au même endroit n’est pas une course de 0 km, il estime qu’il en va de même pour les lignes de code.

• Le rôle en tant qu’employé

  • Un intervenant partage cette leçon : même si l’on est aussi intelligent qu’Einstein, on reste malgré tout un employé, avec les obligations que cela implique.