Rust Re-writes & Chesterton's Fence
Cette vidéo dénonce les réécritures massives de logiciels éprouvés (notamment en Rust) en ignorant les décennies d’expérience et les edge cases accumulés, illustré par le principe de la « clôture de Chesterton ».
SYNTHÈSE STRUCTURÉE
Le problème des réécritures Rust agressives
L’intervenant critique sévèrement les développeurs Rust qui « jettent des logiciels développés pendant des années, voire des décennies » pour les réécrire de zéro. Il souligne que ce n’est pas un problème nouveau, mais qu’il touche particulièrement les utilitaires système comme les GNU coreutils. Le vrai problème n’est pas le langage Rust lui-même, mais l’attitude qui consiste à « ignorer des décennies, voire des siècles de logique de base ».
Chesterton’s fence : une leçon vieille de 100 ans
L’intervenant cite G.K. Chesterton (1929) : « Si vous voyez une clôture sur un terrain, avant de l’enlever, assurez-vous de comprendre pourquoi elle a été construite. » Il applique cette métaphore au code legacy : « Les gens ne construisent pas des choses et ne passent pas beaucoup de temps à traiter des edge cases difficiles pour rien. » Tant qu’on ignore la raison d’être d’un morceau de code, le supprimer risque de causer « une catastrophe de proportion inconnue ».
L’aveu des développeurs Rust sur les edge cases
L’intervenant rapporte qu’un développeur principal de réécritures Rust a admis que le logiciel original couvrait un « nombre absurde de edge cases » et qu’ils ne savaient même pas ce qu’ils devaient couvrir. « Ils supprimaient tout ce vieux code qui couvrait ces edge cases parce que, eh bien, ils n’utilisaient pas ce edge case. Ils ne savaient même pas ce que c’était. Donc, personne n’en avait besoin. »
La règle de Joel Spolsky : ne jamais réécrire de zéro
L’intervenant cite Joel Spolsky (2000) : « Ils ont fait la pire erreur stratégique qu’une entreprise de logiciels puisse faire : décider de réécrire le code de zéro. » Il insiste : « Chaque ingénieur qui a existé et travaillé plus de quelques années a fait cette erreur. » L’astuce est de la faire tôt dans sa carrière, sur des projets à faible impact, pas sur des logiciels utilisés par « des milliards de personnes chaque seconde ».
Le cas Ubuntu : doublement de la mise
L’intervenant observe qu’Ubuntu et d’autres distributions Linux « commettent l’erreur d’ingénierie la plus évidente et la plus simple possible ». Pire, quand on leur a signalé le problème, « ils ont immédiatement creusé leur position » et accéléré le calendrier. Il suggère des motifs cachés possibles : « Réécrire le logiciel pour qu’il utilise une licence différente. Le logiciel qu’ils remplacent est sous licence GPL. Le nouveau logiciel qu’ils écrivent est sous licence MIT. »
L’importance des edge cases dans les logiciels système
Les utilitaires système comme les coreutils « sont remplis d’un nombre incalculable de edge cases parce que ces outils tournent sur une grande variété de systèmes, utilisés dans un nombre incalculable d’environnements et dans une grande variété de circonstances ». Jeter ces edge cases, c’est casser « tout outil, tout workflow, toute personne, toute entreprise qui comptait sur cet utilitaire fonctionnant sous ce edge case ».
La recommandation finale
L’intervenant exhorte les managers et développeurs à lire Chesterton ou au moins à méditer sur l’image de la clôture : « Arrêtez d’enlever la clôture avant de comprendre pourquoi elle a été mise en place. » Il rappelle que l’expérience des ingénieurs chevronnés devrait suffire, mais que si ce n’est pas le cas, « peut-être que G.K. Chesterton vous convaincra ».
CONCEPTS CLÉS
- Chesterton’s fence : Principe philosophique selon lequel on ne doit pas supprimer une chose (une règle, une institution, un morceau de code) sans comprendre pourquoi elle existe. Appliqué au logiciel, cela signifie qu’il faut comprendre les edge cases avant de réécrire.
- Edge case : Cas limite ou situation exceptionnelle qu’un logiciel doit gérer correctement. Dans les utilitaires système, ils sont nombreux et souvent invisibles pour un nouveau développeur.
- Réécriture from scratch : Action de jeter tout le code existant d’un projet pour le réécrire entièrement, souvent dans un nouveau langage. Joel Spolsky la considère comme « la pire erreur stratégique » possible.
- GPL vs MIT : Licences de logiciel libre. La GPL impose que les modifications soient redistribuées sous la même licence ; la MIT est plus permissive. L’intervenant suggère que le changement de licence pourrait être un motif caché des réécritures.
CONCLUSION
Le message principal est que la réécriture de logiciels éprouvés (comme les coreutils GNU) en ignorant les edge cases accumulés sur des décennies est une erreur d’ingénierie fondamentale, illustrée par Chesterton’s fence. L’intervenant appelle à la prudence et à l’humilité face au code legacy, et met en garde contre les décisions motivées par l’inexpérience ou des intérêts cachés. Pour un administrateur système, cela signifie qu’il faut toujours analyser pourquoi un code existe avant de le remplacer, et ne pas céder à la tentation de la « réécriture miracle » sans comprendre l’ensemble des cas d’usage.