Combien de lignes de code par jour ?

Par : Thierry Chatel (@ThierryChatel).
Publié le 28/02/2020.

Ou pourquoi le métier d’un développeur n’est que marginalement d’écrire du code.

Utiliser le nombre de lignes de code par jour comme mesure de la productivité des développeurs est une idée qui devrait aujourd’hui paraître absurde à tout le monde. Alors que ça a pourtant réellement servi par le passé. Notre industrie si prompte à reproduire continuellement les mêmes erreurs est quand même capable de progresser.

Quoi qu’il en soit, avoir en tête un ordre de grandeur du nombre de lignes qu’un développeur écrit en moyenne en une journée de travail n’est pas sans intérêt, tant que ça n’est pas un facteur de rémunération. On va même voir ce que ça peut nous apprendre du métier de développeur.

Des développeurs payés à la ligne de code ?

Est-ce que ça a réellement existé, ou n’est-ce qu’une légende ? Je n’ai pas trouvé de document indiquant de façon fiable qu’il y aurait eu, même aux débuts pas si lointains de l’informatique, des développeurs payés individuellement en fonction du nombre de lignes de code source produites. Mais à une époque où l’idée de vendre un logiciel était tout juste concevable, ça ne semblait peut-être pas absurde. Il n’est pas impossible que des pionniers au tout début aient été payés ou aient touché des primes en fonction du poids de cartes perforées.

carte perforée

Si j’ai précisé “individuellement”, c’est parce qu’il est avéré que le nombre de ligne de code a servi à évaluer la rémunération de prestations de sous-traitance, dans leur globalité. IBM mesurait ça en “kLOCs”, pour “kilo Lines Of Code”. C’est connu notamment par l’exemple célèbre du système OS/2, qui remonte au début des années 90. Pour ceux qui étaient en maternelle à l’époque, OS/2 était un système d’exploitation co-développé par des équipes d’IBM et Microsoft, un avatar bien plus évolué de DOS et Windows. IBM pilotait le projet, et mesurait les kLOCs de chacune des deux entreprises, pour évaluer leur contribution respective. La chose est vivement critiquée par Steve Ballmer dans le documentaire “Triumph of the Nerds” : si un de nos développeurs trouvait une bonne solution pour faire quelque chose en 5 kLOCs au lieu de 20 kLOCs, dit-il dans la vidéo, était-il logique qu’on gagne moins d’argent ?

OS/2

J’approuve entièrement ce point de vue de Steve Ballmer, même si ça me fait mal de le reconnaître — mais j’imagine que même Donald Trump doit parfois dire quelque chose d’intelligent, même si c’est totalement fortuit dans son cas. Cette absurdité du kLOC n’est pas la seule cause du retrait de Microsoft, qui a finalement condamné OS/2. Ceux qui sont assez vieux pour avoir utilisé ce système, j’en fais partie, purent constater qu’il contenait beaucoup de bonnes idées, mais qu’il était aussi très lourd — imaginez, des dizaines de disquettes pour l’époque ! Maximiser les lignes de code est évidemment un très mauvais objectif.

“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”
Bill Gates, ou peut-être pas…

On comprend facilement pourquoi. Le code est d’autant plus lisible, et de qualité, qu’il est à la fois clair et concis. Globalement, moins il y a de code et moins il y a de bugs, de failles de sécurité ou de problèmes en tout genre, et plus c’est rapide à lire et à comprendre. Du moins tant que le code reste clair, car il y a un point optimum en dessous duquel on perd en clarté. Tant qu’on ne tombe pas dans une exagération conduisant à du code cryptique, en règle générale la solution la plus courte sera la meilleure. Ça demande d’ailleurs beaucoup d’expérience pour trouver une solution simple à un problème complexe, alors que n’importe quel débutant pourra imaginer une solution exagérément compliquée.

Mais combien de lignes de code par jour ?

S’il est clair qu’un nombre de lignes de code par jour n’est ni un objectif ni une métrique pertinente, on peut quand même se demander combien en moyenne un développeur qui travaille correctement va produire de lignes de code de production.

C’est difficile de trouver une valeur, ou plutôt de trouver une seule valeur. On voit des études assez pointues, ou des valeurs avancées sans justification réelle. Le calcul est rarement fait en fin de projet, alors que ce n’est qu’une simple division. Dans l’ensemble, on peut trouver des valeurs qui sont surtout dans une fourchette de 10 à 50 lignes de code par jour. La plus plus pessimiste, de 10 lignes, est fournie par le fameux livre “The Mythical Man Month” de Brooks.

Seulement 10 lignes par jour ? C’est quoi cette blague ? Les développeurs sont-ils des feignasses ? Il faut bien comprendre ce que l’on compte. Déjà c’est une valeur moyenne, alors que l’efficacité varie beaucoup d’un développeur à l’autre. Ensuite, ça ne veut pas dire que quand il a écrit ses 10 lignes, un développeur va passer le reste de la journée à glander sur les réseaux sociaux.

procrastination ?

La plupart des jours, un développeur va écrire beaucoup plus de 10 lignes. Mais il y a aussi tous les jours où il lui faut comprendre le besoin, apprendre à utiliser un outil, ou arriver à localiser un bug incompréhensible. Et on parle de lignes du code final, celui livré en production une fois le logiciel stabilisé. Combien de lignes de code ont été écrites en cours de projet, puis supprimées, ou réécrites de nombreuses fois, pour chacune des lignes du code finalement livré ? On fait du refactoring, on supprime de grandes portions de code quand on trouve une meilleure solution… Pour comparer avec un écrivain, ici on ne regarde pas tout ce qui a été écrit au brouillon, mais uniquement le nombre de lignes du livre publié.

Dans ces conditions, ça paraît nettement plus logique, et à mon avis le haut de la fourchette avec une moyenne de 50 lignes par jour est très optimiste. Je pense que ça se situe beaucoup plus souvent dans les 10 à 30 lignes par jour. Sauf dans l’aviation, où ça doit être bien en dessous des 5 lignes.

Développer, ce n’est pas taper du code

Taper 30 lignes par jour, c’est l’affaire de quelques minutes. Un développeur doit passer à peu près autant de temps à taper le code qu’un garagiste à se laver les mains. Certes, la comparaison est fallacieuse, car le développeur aura écrit bien plus de lignes que celles qui finissent livrées en production, et il y aura passé plus de temps. Et puis quand même, le lavage des mains n’est pas la finalité de la mécanique, alors que les lignes du code de production sont bien celle de l’informatique.

taper du code

Mais en est-on vraiment sûr, que le code est la finalité ? On peut voir plutôt le code comme un artifice, si l’on considère que la finalité est l’automatisation d’un processus. On écrit du code parce que c’est la seule chose qu’est capable de comprendre un ordinateur, l’objectif réel étant juste de faire exécuter une tâche à cette stupide machine. Le code n’est pas une fin en soi, mais moyen de décrire sans ambiguïté une tâche à accomplir. Ce qui suppose d’abord de la comprendre précisément, et ensuite de l’exprimer précisément, de façon parfaitement univoque, ce que ne permet aucun langage humain.

Développer, c’est modéliser.

On peut imaginer aussi donner des instructions à un ordinateur sans utiliser de code. C’est l’objectif de l’ingénierie des modèles, l’idée étant de spécifier une application par un modèle très détaillé, au point qu’il devient une spécification exécutable, souvent après génération de code. On peut objecter qu’un modèle exécutable, ce n’est qu’une autre forme de code, écrit dans un langage bien moins pratique. C’est vrai. Mais il est intéressant de se pencher sur la réciproque : le code est en lui-même une modélisation.

Quand on compare l’ingénierie logicielle à la construction de bâtiments, on fait fausse route. L’écriture du code n’est pas apparentée à la pose de parpaings, mais plutôt à la création du plan du bâtiment. C’est de la conception, du début à la fin, avec des choses classiques ou assez banales et d’autres beaucoup plus complexes, comme on peut faire les plans d’une maison très ordinaire ou d’un bâtiment beaucoup plus original et innovant. En informatique, la réalisation (la pose de parpaings) correspond juste la phase de build et de déploiement.

Coder c'est tracer des plans

Coder c’est donc concevoir, abstraire, modéliser. C’est tracer les plans d’un logiciel. Ce qui suppose bien sûr d’avoir bien compris le contexte, le besoin, et comment le logiciel doit fonctionner. Le code source produit reflétera la compréhension du développeur. Par rapport à tout ça, taper le code est juste anecdotique.

Trop d’incompréhension du métier de développeur

Développeur, c’est un métier créatif, impliquant des individus tous différents, avec leurs connaissances, leurs compétences, leur efficacité, etc.

Hélas, beaucoup de ceux qui travaillent avec des développeurs ne l’ont pas compris, comme s’ils ne faisaient pas la différence entre un artiste-peintre et un peintre en bâtiment. Franchement, vous auriez pris Léonard de Vinci pour refaire la peinture de votre séjour, alors qu’il lui a fallu 15 ans pour peindre la Joconde, ce truc minuscule ?

Certes, peu de développeurs sont de très grands artistes du code, mais ignorer que c’est un travail essentiellement créatif entraîne de nombreuses absurdités dans l’industrie du logiciel. Comme le recrutement par “grep” sur les mots-clés d’un CV, j’y reviendrai dans un futur article sur les compétences des développeurs.

Le manque de formation découle aussi de cette mauvaise compréhension, parfois aussi par un excès de confiance des développeurs eux-mêmes. Si l’on me donne un langage ou un framework, j’arriverai bien l’utiliser. Si l’on me donne un marteau, je saurai bien planter des clous — certes. Si l’on me donne un dictionnaire, j’arriverai bien à parler chinois — là c’est tout de suite beaucoup moins crédible. Un langage, un framework, c’est d’abord la mise en œuvre d’un paradigme, d’une façon de modéliser un problème. Sans une compréhension approfondie, on l’utilise mal et on fait n’importe quoi. Dira-t-on d’un iPhone qu’il est un mauvais outil si on l’utilise comme un marteau pour essayer de casser une noix de coco ?

pair programming

Pour finir, voici un argument que je donne aux développeurs, pour la prochaine fois où votre chef de projet vous dira qu’on n’a pas le temps de travailler en binôme, parce que si une seule personne tape du code au lieu de deux, ça prendra forcément deux fois plus de temps. Vous pourrez lui expliquer que taper le code, c’est moins de 10 % du temps de développement. Et que sur les 90 % restants, sur la conception, deux cerveaux travaillant ensemble sont plus efficaces que séparément pour résoudre un problème.