The Worst Software Engineering Mistake Deciding to Rewrite the Code from Scratch
L'intervenant met en garde contre la tentation dangereuse et récurrente de réécrire intégralement un codebase fonctionnel, en s'appuyant sur l'article fondateur de Joel Spolsky et en pointant du doigt des projets contemporains comme Ubuntu qui, selon lui, commettent cette ...
SYNTHÈSE STRUCTURÉE
La loi fondamentale : ne jamais tout réécrire
L’intervenant rappelle une règle cardinale apprise à la dure par les développeurs expérimentés des années 80 à 2000 : réécrire un logiciel fonctionnel à partir de zéro est une erreur stratégique majeure, conduisant presque toujours à un échec. Il cite Joel Spolsky : “the single worst strategic mistake that any software company can make. They decided to rewrite the code from scratch.” Cette décision signifie abandonner des années de corrections de bugs, d’optimisations et de connaissances accumulées dans l’ancien code, qui fonctionne et génère des revenus.
L’illusion du “code propre” et la difficulté de lecture
Les développeurs sont naturellement attirés par l’idée de repartir de zéro car ils perçoivent le code existant comme un “gros bazar”. L’intervenant explique que cette perception découle d’une loi fondamentale : “It is harder to read code than to write it.” Une fonction longue et complexe n’est pas nécessairement mauvaise ; elle est souvent le résultat de nombreux correctifs pour des cas limites spécifiques (bug lié à un disque dur externe retiré, compatibilité avec de vieilles versions de Windows, etc.). Chaque ligne obscure représente un problème résolu.
Les conséquences désastreuses : perte de temps et de parts de marché
Réécrire implique de perdre 2 à 3 ans d’avance, un délai énorme dans l’industrie logicielle, et offre un cadeau inestimable à la concurrence. L’intervenant rappelle les exemples historiques donnés par Joel Spolsky : Netscape, Borland avec dBase et Quattro Pro, ou le projet “Pyramid” avorté de Microsoft Word. Ces entreprises ont soit disparu, soit vu leur domination s’effriter à cause de cette décision.
Le cas moderne et aggravé : le “ship early” avec du code réécrit
La situation est pire aujourd’hui qu’à l’époque des versions monolithiques. L’intervenant cible spécifiquement Ubuntu : “Abuntu ships a brand new version of Abuntu every six months and regularly updates the software… they’re shipping the brand new rewritten from scratch code.” Au lieu de geler les livraisons le temps de réécrire, ils livrent du code neuf, non testé et potentiellement instable à leurs utilisateurs finaux. Le risque n’est plus de livrer lentement, mais de “shipping crap” et de détruire sa réputation.
Le rôle crucial du management pour contenir les impulsions
L’intervenant, se présentant comme un ancien ingénieur et manager, souligne que le désir de tout réécrire est une pulsion naturelle et constante chez les développeurs, même les plus talentueux. Le rôle du management est de canaliser cette énergie vers l’amélioration incrémentale. Il reprend une citation de Steven Sinofsky (ex-Microsoft) : “developers left to their own would gladly plan the next release as retyping all their code using new tools… Our role in project management is to help them avoid that.” Il faut des managers expérimentés pour dire “non”.
L’expérience perdue : une génération qui n’a pas appris la leçon
L’intervenant estime que la génération actuelle de développeurs et de managers, souvent citée pour vouloir tout réécrire en Rust par exemple, n’a pas l’expérience ou a oublié ces leçons douloureuses. “They don’t have the experience to know these important lessons… or for some reason they’ve forgotten it.” Il n’y a plus assez de “barbes grises” pour imposer la sagesse de l’itération sur la révolution.
CONCEPTS CLÉS
- Réécriture complète (“Rewrite from scratch”) : Abandonner l’ensemble du code existant d’une application pour en recommencer une nouvelle version à zéro. Considéré comme une erreur stratégique majeure.
- Dette technique vs. connaissance embarquée : Le code ancien peut sembler désordonné (dette), mais il contient une précieuse “connaissance embarquée” sous forme de correctifs pour des bugs rares et des cas limites.
- Développement incrémental/itératif : Philosophie opposée à la réécriture, prônant l’amélioration continue, le refactoring et l’ajout de fonctionnalités au codebase existant.
- “Ship early, ship often” : Pratique moderne de livraison fréquente de logiciels. Dangereuse lorsqu’elle est couplée à l’utilisation de code nouvellement réécrit et non éprouvé.
CONCLUSION
Le message principal est un avertissement sévère contre l’orgueil et l’inexpérience qui poussent à vouloir tout réécrire. La valeur d’un logiciel ne réside pas seulement dans son élégance algorithmique, mais dans la somme colossale de connaissances et de corrections accumulées au fil des années, souvent invisibles. Ignorer cette sagesse collective, comme l’illustre la critique d’Ubuntu, c’est risquer de livrer des produits instables, de perdre la confiance des utilisateurs et de céder son avance stratégique. L’intervenant appelle à un retour à l’humilité et à l’approche itérative, en rappelant que “Old code has been used. It has been tested. Lots of bugs have been found and they have been fixed.” 🧠 Ce débat est crucial car il touche au cœur de la fiabilité, de la productivité et de la pérennité des projets logiciels.