Non, jamais. Le nombre de lignes de code n'est pas la productivité d'un développeur.

Quand le nombre de lignes de code est mesuré et valorisé dans une entreprise, immédiatement il est artificiellement gonflé par les développeurs qui préféront toujours dupliquer du code fonctionnel pour traiter un nouveau cas plutôt que de le généraliser et le réduire, puis cette attitude conduit inexorablement à ralentir la vitesse de développement de modifications dans un code toujours plus gros et plus lourd.

Quand vous dîtes "productivité", il est important de bien comprendre ce que vous voulez mesurer. Généralement ce qui a de la valeur in fine c'est uniquement les fonctions du logiciel, si bien qu'en première approximation, la productivité d'un développeur peut être la mesure du nombre de tickets qu'il ferme par jour ou par semaine, en prenant soin de vérifier qu'un ticket ne représente toujours qu'une seule fonction, une seule problématique, un seul sujet. En tout cas ceci a du sens tant qu'on crée un nouveau logiciel.

Ensuite après la phase de création on passe à une phase de maintenance qui consiste à fermer des tickets d'incident. Dans une telle phase, on aurait tendance à mesurer là encore le nombre de tickets fermés, mais ça serait une erreur car beaucoup d'incidents veut dire que le code concerné a été bâclé, soit en étant codé maladroitement (responsabilité du maître d'œuvre, le développeur) soit qu'il a été beaucoup modifié (responsabilité du maître d'ouvrage, le client).

Mais quelque soit l'origine des incidents, il n'est pas acceptable de les considérer de la même façon que de la production de nouvelles fonctionnalités.

• J'appelle "faire des m²" l'étape initiale de création d'un logiciel lorsque la vitesse de fermeture de tickets est grande. Appelons-là la phase A.
• Puis il y a une deuxième étape qui consiste à ajuster les mécanismes, fignoler (traiter les cas rares, les corner cases), rendre ergonomique. Ce sera la phase B.
• Et enfin, la troisième étape est toujours la correction des tickets d'incident. C'est la phase C.

Quand on veut évaluer correctement la productivité d'un développeur, on va donc plutôt compter la vitesse de fermeture des tickets fermés pendant la phase de création du logiciel (la phase A) puis on va regarder également la vitesse de fermeture des tickets des phases de création et ajustements (phases A+B), et enfin on fera la moyenne totale (phase A+B+C) mais sans compter les tickets de la phase C comme de la performance, puisque ça ne l'est pas (ces tickets-ci ne représentant pas de fonctionnalités).

La phase A donnera la "performance brute" du développeur, les phases A+B donneront une "performance réaliste" et idée du coût minimum de fabrication du logiciel, et les phases A+B+C donneront une bonne idée du coût total, et donc de la "performance totale" telle que :

• performance totale = (nb tickets A fermés + nb tickets B fermés) / (temps A + temps B + temps C)