Moins 2 000 lignes de code
(folklore.org)- Au de9but de 1982, l9quipe logicielle de Lisa, sous la pression d9une sortie dans les 6 mois, a cherche9 e0 mesurer l9avancement par le nombre de lignes de code hebdomadaire de chaque inge9nieur
- Bill Atkinson estimait que le nombre de lignes ne refle9tait pas correctement la productivite9 et allait e0 l9encontre de l9objectif de cre9er des programmes petits et rapides
- En re9e9crivant le moteur de calcul des re9gions de QuickDraw avec un algorithme plus simple et plus ge9ne9ral, les ope9rations sur les re9gions sont devenues presque 6 fois plus rapides et le code a diminue9 d9environ 2000 lignes
- Dans le premier formulaire de gestion, e0 la case demandant le nombre de lignes de code e9crites cette semaine-le0, Bill a inscrit
-2000, exposant tel quel la faille de cette me9thode de mesure - Quelques semaines plus tard, les managers ont cesse9 de demander ce formulaire e0 Bill, et cette anecdote montre qu9une gestion fonde9e sur le nombre de lignes de code peut passer e0 cf4te9 de ve9ritables ame9liorations
Mesurer les lignes de code dans l9e9quipe Lisa
- Au de9but de 1982, l9quipe logicielle de Lisa voulait acce9le9rer le rythme de travail afin de livrer le logiciel dans les 6 mois suivants
- Certains managers ont essaye9 de suivre l9avancement en fonction du nombre de lignes de code e9crites chaque semaine par chaque inge9nieur
- Les inge9nieurs recevaient un formulaire e0 remettre chaque vendredi, comprenant une case of9 indiquer le nombre de lignes de code e9crites cette semaine-le0
Le -2000 de Bill Atkinson
- Bill Atkinson, auteur de QuickDraw et principal concepteur de l9interface utilisateur, jouait un rf4le essentiel dans l9imple9mentation de Lisa
- Bill conside9rait que l9indicateur des lignes de code ne mesurait pas correctement la productivite9
- Il pensait que l9objectif d9un bon logiciel e9tait d9e9crire des programmes aussi petits et rapides que possible
- Un indicateur qui re9compense l9augmentation du nombre de lignes peut encourager l9e9criture d9un code maladroit, lourd et bogue9
- c0 cette e9poque, il optimisait le moteur de calcul des re9gions de QuickDraw
- Il a entie8rement re9e9crit le moteur des re9gions avec un algorithme plus simple et plus ge9ne9ral
- Apre8s ajustement, les ope9rations sur les re9gions sont devenues presque 6 fois plus rapides
- En meame temps, le code a diminue9 d9environ 2000 lignes
- En remplissant le premier formulaire de gestion, il a regarde9 un instant la case sur le nombre de lignes de code, puis a inscrit
-2000 - On ne sait pas exactement comment les managers ont re9agi, mais quelques semaines plus tard, ils ont cesse9 de lui demander de remettre le formulaire
1 commentaires
Avis sur Hacker News
Cela me rappelle l’exemple du conflit sur le nombre de lignes de code entre Microsoft et IBM
Dans la série télévisée de PBS basée sur Accidental Empires de Bob Cringely, on voit Steve Ballmer raconter son expérience de codéveloppement d’OS/2 avec IBM
Microsoft avait l’attitude d’une petite entreprise qui veut terminer le travail, tandis qu’IBM se concentrait sur ses indicateurs internes, en particulier la productivité des programmeurs mesurée en KLoC (milliers de lignes de code)
Ballmer disait : « tout ce qui les intéressait, c’était les KLoC, les KLoC, et encore les KLoC », et IBM semblait regarder davantage la quantité que la qualité du code
https://ubiquity.acm.org/article.cfm?id=1022357
Ceux qui savaient de quoi il retournait ont vécu cette « célébration » comme un enterrement
Compter les lignes de code comme indicateur de productivité est vraiment idiot
J’ai déjà corrigé en une seule ligne un bug insoluble vieux de 20 ans, et je me souviens d’un bug vieux de 3 ans résolu avec un simple
order by. Comment mesurer l’impact d’une ligne de code ? D’après mon expérience, les mauvais programmeurs écrivent beaucoup plus de codeJe n’oublierai pas non plus l’histoire[1] du développeur Microsoft qui a réécrit un code IBM de 33 000 caractères pour le ramener à 220 caractères. Résultat : la charge de travail de Microsoft est devenue « négative », ce qui aurait déclenché une guerre
[1] https://archive.org/details/bigbluesunmaking00carr/page/4/mode/2up p. 101
Un exemple actuel : certaines entreprises prennent « l’impact », c’est-à-dire le lancement de nouveaux produits, comme critère de promotion. C’est une bonne recette pour se retrouver avec quantité de produits ratés que plus personne ne maintient
Parmi les grands informaticiens et ingénieurs, certains ont produit une quantité énorme de code, et je crois que cela se traduit directement, d’une manière ou d’une autre, en impact. Le problème survient au moment où le nombre de lignes de code devient un indicateur de performance
C’est là que s’applique la loi de Goodhart : « lorsqu’une mesure devient un objectif, elle cesse d’être une bonne mesure »
Du point de vue des indicateurs de productivité, le code est classé comme un actif ; mais une vision plus proche de la réalité consiste à dire que les fonctionnalités sont des actifs, tandis que le code lui-même est une dette
Ce sujet revient souvent. Voici les discussions précédentes
https://news.ycombinator.com/item?id=33483165 (2022)
https://news.ycombinator.com/item?id=26387179 (2021)
https://news.ycombinator.com/item?id=10734815 (2015)
https://news.ycombinator.com/item?id=7516671 (2014)
https://news.ycombinator.com/item?id=4040082 (2012)
https://news.ycombinator.com/item?id=1114223 (2010)
https://news.ycombinator.com/item?id=1545452 (2010)
Au début de ma carrière, j’ai optimisé un programme C de plus de 10 000 lignes dont j’avais hérité pour le ramener à moins de 500 lignes. C’était un programme C qui effectuait des appels SQL vers une base de données Sybase
Ce n’était pas dû à une grande intuition, mais simplement à l’hypothèse que mon prédécesseur ne savait peut-être pas utiliser les fonctions, ni les paramètres pour injecter des données variables dans les requêtes SQL. De fait, les mêmes instructions SQL étaient écrites inline encore et encore, avec seulement quelques valeurs qui changeaient
J’ai réécrit le code des appels SQL sous forme d’appels de fonction, avec les variables de liaison passées comme paramètres de fonction. Le code inline répété a été remplacé par une boucle qui prend les valeurs de liaison variables dans un tableau et appelle la fonction
L’impact le plus important vient parfois du fait de poser une question simple du type « comment va-t-on gérer X ? », et d’empêcher ainsi carrément la construction de quelque chose.
Si cette chose n’a même jamais eu l’occasion de fonctionner correctement, on a économisé tout le coût de la tentative de la construire.
Ce genre de chose est non seulement impossible à mesurer avec des indicateurs chiffrés, mais peut aussi vous créer des ennemis. J’applaudis tout de même ceux qui osent le faire.
Les gens qui voient la programmation comme quelque chose de proche de la frappe rapide présentent une analogie intéressante avec les LLM : ils écrivent tout un tas de code mal conçu, l’effacent, puis le réécrivent et l’effacent à nouveau.
Environ la moitié des demandes d’information qui arrivaient dans le service étaient toujours du genre « c’est très important, il nous le faut tout de suite, et cela peut rapporter ou économiser beaucoup d’argent », mais la réponse évidente était : « Calculez-le avec les informations que vous avez déjà. Vous avez des calculatrices et des tableurs, non ? Vous voulez un crayon ? »
Il vaut mieux éviter de faire en sorte que le système gère X. Un cas particulier qui servira une ou deux fois, tout au plus, fait gonfler le système, et plus personne ne sait que ce cas particulier ou ce programme existe, ni ce qu’il fait réellement. Même avec une bonne documentation, les gens ne prennent pas le temps d’apprendre ce qui est possible. La plupart de ces fonctionnalités spéciales finissent donc, en pratique, par être une perte de temps.
On peut imaginer l’expérience de pensée inverse. Si un manager lisait cet article et décidait naïvement de mesurer les gens au nombre de lignes de code supprimées, est-ce que cela améliorerait les choses, ou les empirerait ?
Ce type de mesure est globalement presque inutile en l’absence de pratiques de revue de code solides. Contrairement à ce que les gens ici aimeraient croire, de telles pratiques sont rares. Mais si de bonnes revues existent, elles permettent aussi de repérer les faibles performances ou la manipulation des métriques, ce qui réduit d’emblée l’intérêt d’introduire ce genre d’indicateur.
Par exemple, il existe depuis longtemps l’idée de supprimer complètement les ingénieurs logiciel et le texte de code ésotérique, pour les remplacer par des product managers dessinant des diagrammes ou des organigrammes spéciaux afin de produire des résultats en « low-code » ou « no-code ».
En comptant séparément les lignes ajoutées et supprimées, un patch
+50,-150compterait pour 200 ΔSLOC.Ce n’est pas une bonne mesure de la productivité, surtout pas utilisée seule. Mais comme calcul approximatif, au doigt mouillé, du volume de changement, c’est raisonnable. Savoir si un développeur avec un ΔSLOC élevé est plus productif qu’un collègue qui n’a aucun ΔSLOC pendant une ou deux semaines dépend de ce que fait ce collègue, mais il est certain que, sur la période mesurée, le premier modifie davantage la base de code.
Si le produit est « terminé », cela pourrait être équivalent, voire mieux. Sinon, les changements à nombre de lignes négatif n’arriveraient pas jusqu’au déploiement.
Mais la plupart des produits continuent d’évoluer. C’est pour cela que nous pouvons rester plusieurs années sur les mêmes projets, et les contributions qui ne font que supprimer du code finissent par ne rien apporter.
La vraie histoire, c’est que lorsqu’on démarre un projet, on ne sait pas toujours exactement où l’on va.
Au fil de l’avancement, on comprend beaucoup mieux le problème et la réponse souhaitée, ce qui permet d’arracher de gros morceaux pour les remplacer par quelque chose de plus petit et de meilleur.
Et il ne faut pas oublier que ces personnes devaient faire tenir tout cela, y compris
-2000lignes de code, et même du code assembleur, dans une ROM de 64 Ko. La pression pour réduire la taille était très forte.Je ne suis même pas sûr qu’il se trouvait réellement en ROM plutôt que sur la disquette de démarrage. Au passage, d’après Wikipedia, la ROM du Lisa faisait 16 Ko.
[1] https://computerhistory.org/blog/the-lisa-apples-most-influential-failure/
[2] https://computerhistory.org/blog/macpaint-and-quickdraw-source-code/
Il s’agit de Bill Atkinson, célèbre pour le dithering d’Atkinson. https://beyondloom.com/blog/dither.html
Dans ce processus, il a constamment dû inventer de nouvelles façons de faire fonctionner les interfaces utilisateur, ainsi que des manières d’écrire le logiciel pour les réaliser. Il optimisait à la fois pour que cela puisse « tourner rapidement sur le matériel du Mac » et « offrir une excellente expérience utilisateur », et cette synergie a laissé son empreinte sur toute l’esthétique des anciens Mac en noir et blanc. Ce style de dithering est lui aussi un autre exemple de combinaison entre génie algorithmique et sens esthétique.
Ce sens se manifeste aussi dans des choses comme la bordure de sélection en « marching ants » (https://en.wikipedia.org/wiki/Marching_ants). Il en va de même pour une grande partie du feedback de l’interface classique du Mac, exprimé par inversion des pixels : la sélection de texte, la mise en surbrillance des menus, l’apparence des boutons pendant qu’on maintient le bouton de la souris enfoncé, les contours lors du déplacement d’une fenêtre, etc. Dessiner par-dessus en mode XOR était une très bonne manière de produire ce type d’effet.
La façon dont ces outils ont été combinés dans QuickDraw a fait que la célèbre discussion avec Steve Jobs sur les rectangles arrondis (https://www.folklore.org/Round_Rects_Are_Everywhere.html) a effectivement abouti à ce qu’il devienne aussi facile de dessiner des rectangles arrondis que des rectangles dans QuickDraw, ce qui a fait apparaître des rectangles arrondis partout dans le système d’exploitation.
Le succès de l’interface du Mac ne tenait pas seulement à son apparence. Il tenait en grande partie au fait que Bill Atkinson avait créé un petit ensemble d’outils ingénieux qui rendait facile de produire quelque chose de beau.
Les excellentes icônes de Susan Kare n’auraient pas non plus été gardées avec autant d’affection en mémoire si Bill n’avait pas créé les outils permettant d’intégrer facilement à l’interface des bitmaps de masque de 32x32 pixels et de les inverser au clic.
La leçon, c’est que même si l’on est aussi intelligent qu’Einstein, on reste au fond un employé, et il faut faire ce qu’un employé doit faire.
Je n’ai jamais compris pourquoi, quand les gens parlent du nombre de lignes de code écrites, ils calculent toujours « lignes ajoutées - lignes supprimées ».
Ce n’est pas parce que je fais une course de 10 km et que je reviens au point de départ que j’ai couru 0 km.
Par exemple, transformer une forme
if cond { ... return; } ...enif cond { ... return; } else { .... }.Mais cette explication ne couvre pas tout pour autant.