Par Joel Spolsky, le 6 avril 2000.

Vous trouverez l’original ici

Netscape 6.0 est sur le point de publier sa première version beta. Il n’y a jamais eu de version 5.0. La derniere version majeure était la 4.0, dévoilée il y a presque trois ans. Trois ans, c’est une durée horriblement longue dans le monde Internet. Pendant ce temps, Netscape était assis, sans rien pouvoir faire d’autre que de voir leurs ventes s’écrouler.

C’est un peu ingrat de ma part de les critiquer sur le temps d’écart entre les versions principales. Ils ne l’ont pas fait volontairement, n’est-ce pas ?

Eh bien si, c’était volontaire. Ils ont fait la seule et unique, la pire erreur stratégique qu’une entreprise puisse faire :

Ils ont décidé de réécrire le code en entier.

Netscape n’était pas le première société à faire cette erreur. Borland a fait la même erreur lorsqu’ils ont acheté Arago et essayé de l’intégrer dans dBase pour Windows, un projet maudit qui a pris tellement de temps que Microsoft Access a mangé leur déjeûner, et puis ils l’ont recommencé avec Quattro Pro, en repartant à nouveau de zéro, en épatant les gens sur le nombre impressionnant du peu de possibilités qu’il avait. Microsoft a fait presque la même erreur, en essayant de ré-écrire Word pour Windows à partir de zéro, dans un projet lui aussi maudit appelé Pyramid qui a été stoppé, jeté, balayé et caché sous le tapis. Par chance pour Microsoft, ils n’ont jamais cessé de travailler sur le vieux code, donc ils ont eu quelque chose à vendre, transformant tout ça simplement en un désastre financier, et non pas un désastre stratégique.

Nous sommes des développeurs. Les développeurs sont, au plus profond d’eux-mêmes, des architectes, et la première chose qu’ils veulent faire quand ils arrivent dans un chantier est de tout raser, et de faire quelque chose de grand. Nous ne sommes pas excités par la rénovation incrémentale : le bricolage, l’amélioration, et planter des parterres de fleurs.

Il y a une raison subtile qui explique pourquoi les développeurs veulent systématiquement tout jeter et recommencer. La raison est qu’ils pensent que le vieux code est bordélique. Est c’est là que vient une observation intéréssante : ils se trompent très certainement. La raison pour laquelle ils pensent que le code est un bazar, est dûe à une loi de programmation simple, cardinale et fondamentale :

C’est toujours plus dur de lire du code que de l’écrire.

C’est pourquoi réutiliser du code est si difficile. C’est pourquoi dans votre équipe, chacun a sa propre fonction, unique, qu’il aime utiliser pour casser des chaines en tableau d’autres chaines. Ils écrivent leur propre fonction parce que c’est plus facile et plus sympa à faire que d’essayer de comprendre comment on se sert de la vieille fonction.

Un corollaire de cet axiome est que vous pouvez demander à pratiquement n’importe quel développeur aujourd’hui ce qu’il pense du code qu’il sur lequel il travaille. “C’est un bordel total,” vont-ils vous dire. “La seule chose que j’aimerais vraiment est de tout jeter et recommencer proprement.”

Pourquoi est-ce un foutoir ?

“Eh bien,” vous disent-ils, “regarde cette fonction. Elle s’étale sur deux pages ! Il n’y a rien dedans qui appartient réellement à la fonction ! Je ne sais même pas à quoi sert la moitié des appels faits aux API.”

Avant que la nouvelle brochure de Borland pour Windows ne sorte, Philippe Kahn, le fondateur très coloré de Borland, a été cité souvent dans la presse en vantant à quel point Quattro Pro serait meilleur que Microsoft Excel, parce qu’il avait été entièrement ré-écrit. Que du nouveau code source ! Comme si le code source pouvait rouiller.

L’idée qu’un code nouveau est meilleur qu’un code ancien est foncièrement absurde. Le vieux code a été utilisé. Il a été testé. Plein de problèmes ont été soulévés, et ils ont été résolus. Il n’y a aucun problème avec ça. Il ne va pas créer de nouveaux bogues juste en restant assis dans le disque dur sans bouger. Au contraire, baby ! Est-ce qu’un programme est supposé être comme une voiture, il rouille inévitablement ? Est-ce qu’un programme est comme une peluche qui devient grossière et laide si elle n’est pas faite avec un nouveau matériel ?

Revenons à notre fonction qui s’étale sur deux pages. Oui, je sais, c’est juste une fonction très simple qui affiche une fenêtre, mais elle a un peu grandi et semble avoir grossi inutilement, et personne ne sait pourquoi. Eh bien je vais vous le dire, pourquoi : ce sont des résolutions de bogues. L’un deux résoud le problème que Nancy a eu lorsqu’elle a essayé d’installer le programme sur un ordinateur qui n’avait pas Internet Explorer. Un autre résoud ce bogue qui ne sort que dans les cas où on a très peu de mémoire. Un autre résoud le problème du fichier qui est sur un périphérique externe (disquette, clé USB) et qui se voit retirer en plein milieu d’une opération d’écriture. Cet appel à LoadLibrary semble pourri mais le code fonctionne aussi sur des anciennes version de Windows 95.

Chacun de ces bogues a pris des semaines et des semaines d’usage intensif en situation réelle avant qu’ils n’aient été trouvés. Le développeur peut avoir passé plusieurs jours avant de réussir à reproduire le bogue dans le laboratoire, et de l’avoir résolu. Si c’est comme la plupart des résolutions de bogues, la solution ne prend qu’une ligne, ou tout juste la modification de quelques caractères, mais un travail énorme a été fait dans ces “quelques caractères”.

Quand vous jetez du code et recommencez tout à zéro, vous jetez aussi toute cette connaissance qui va avec. Toutes ces corrections de bogues. Des années de travail de programmation.

Vous jetez en réalité ce qui fait que vous êtes en tête dans votre catégorie. Vous donnez, comme ça, gratuitement, un ou deux ans à vos concurrents, et croyez moi, c’est une durée énorme quand on parle de logiciels informatiques.

Vous vous mettez vous-même dans une position extrêmement dangereuse, dans laquelle vous allez continuer à livrer une vieille version avec du vieux code pendant encore quelques années, quelque chose qui sera donc voué à ne pas évoluer et à ne pas réagir à des nouvelles choses que le marché va demander, parce que vous ne pourrez pas intégrer un nouveau code. Si vous n’avez pas les reins solides, vous risquez carrément de couler et de fermer votre boîte.

Vous perdez une somme d’argent colossale à réécrire du code qui existe déjà.

Est-ce qu’il y a une alternative ? Il faut tout de même admettre que le vieux code de base de Netscape était vraiment très mauvais. Eh bien, dans tous les cas, il pouvait être mauvais mais vous savez quoi ? Il fonctionnait super bien sur un nombre impressionnant d’ordinateur différents, dans le monde entier.

Lorsque les développeurs vous disent que leur code est un bordel pas possible (c’est toujours le cas à un moment ou à un autre), il y a trois choses qu’il faut inspecter.

1. Il y a des problèmes de conception. Le code n’est pas correctement conçu. Le code concernant les échanges réseaux ouvre ses propres boites de dialogue n’importe quand ; cela aurait dû être mieux géré, et surtout ailleurs. Ces problèmes peuvent être résolus, un par un, en déplacant le code avec précaution, en le mettant à jour, et en généralisant à un seul endroit l’affichage des boites de dialogue. Un seul et unique développeur qui travaille sérieusement et qui vérifie un à un, pas à pas, chacun de ses changements, peut faire cela. Je dis un seul, pour que les autres ne soient pas dans l’impossibilité de travailler. Même les changements majeurs d’architecture peuvent être faits sans changer complètement le code. Sur le projet Juno, nous avons passé plusieurs mois à ré-architecturer autour d’un point central : simplement déplacer le code, le nettoyer un peu, créer des classes de base dont le nom et le principe de fonctionnement soit logique, et créer des interfaces d’échanges claires et précises entre les différents modules. Mais on l’a fait précautionneusement, avec notre code de base, et nous n’avons généré aucun nouveau bogue, et cela sans jeter quoi que ce soit de notre vieux code.
2. Les développeurs pensent que leur code n’est pas optimisé et qu’il est lent. Une rumeur disait que le moteur de rendu de Netscape était lent. Cela n’affectait qu’une petite partie du projet, qu’il était possible d’optimiser ou de ré-écrire. Il n’était pas nécessaire de tout ré-écrire. Lorsqu’on optimise pour la vitesse, 1 % du travail vous donne 99 % des résultats attendus.
3. Enfin, le code est devenu, avec le temps, illisible. Un projet sur lequel j’ai travaillé avait un type de données appelée ChaineEnBordel. Un autre projet avait commencé en utilisant, par convention, l’écriture de toutes les variables membres par un underscore, puis a changé plus tard pour quelque chose de plus standard, “m_”. Donc la moitié des fonctions commencaient par “_” et l’autre moitié par “m_”. Ce qui rendait le code difficilement lisible. Honnêtement, c’est le type de chose que vous résolvez en 5 minutes avec une macro dans Emacs, pas la peine de repartir de zéro.

Il est très important que vous vous souveniez de cela : lorsque vous repartez de zéro, il n’y a aucune raison de croire que vous allez faire un meilleur boulot que celui que vous avez fait la première fois. Premièrement, vous n’aurez peut-être pas la même équipe de développeurs à gérer. Si cela se trouve, ce ne sera même qu’une équipe de nouveaux développeurs, et donc il n’auront pas “plus d’expérience”. Vous allez dans ce cas refaire à nouveau les mêmes erreurs, et à l’inverse créer de nouveaux problèmes qui n’existaient pas dans la version originale.

Le vieux mantra “construirez en un puis jetez le” est très dangereux, et encore plus lorsqu’il concerne des grosses applications commerciales. Si vous écrivez du code de manière expérimentale, vous voudrez peut-être supprimer la fonction que vous avez écrit la semaine précédente, parce que vous venez de penser à un meilleur algorithme. Très bien. Vous voudrez peut-être factoriser une classe pour la rendre plus facile à utiliser. Très bien aussi. Mais jeter complètement programme est une folie furieuse, et si Netscape avait eu une hiérarchie, et une hiérarchie qui supervisait le projet de manière adulte, avec une expérience dans le domaine du logiciel industriel, ils ne se seraient peut-être pas tiré une balle dans le pied si violemment.