Ken thompson, le père fondateur de unix, c et go, dit : 'il est plus productif de supprimer le code inutile'
Depuis plus de cinquante ans, Ken Thompson a laissé son empreinte sur l'histoire du logiciel. Co-créateur de Unix, concepteur du langage B, qui précède directement C, et co-créateur de Go, il a laissé un impact inégalé dans la création de logiciels. C'est pourquoi, lorsqu'il affirme que l'un de ses jours les plus productifs a été celui où il a supprimé 1 000 lignes de code, il vaut mieux le prendre au sérieux.
Thompson, la philosophie de la minimalité et de la complexité réduite
Ken Thompson commence à marquer l'histoire du logiciel à la fin des années 1960, lorsqu'il développe Unix aux laboratoires Bell en collaboration avec Dennis Ritchie. Ce n'est pas seulement un système d'exploitation, c'est une façon de comprendre l'informatique. Avec des outils petits, modulaires qui font une chose bien et se combinent entre eux, il adopte une philosophie de construction minimale et efficace qu'il accompagnera dans chaque projet ultérieur.
Le langage B, conçu par Thompson comme successeur de BCPL, a posé les bases pour que Ritchie développe C, le langage de programmation qui a été pendant des décennies le standard absolu pour la programmation de systèmes. Décennie après décennie, à Google, Thompson co-crée Go, un langage pensé pour les systèmes de production à grande échelle qui répète le même patron : la simplicité au-dessus de la sophistication, la clarté au-dessus de la complexité.
« Chaque ligne de code ajoutée est également une ligne que quelqu'un doit lire, comprendre et maintenir. C'est un point de plus où un bug peut se cacher, un endroit supplémentaire à couvrir avec des tests et une pièce de plus qui complique les futures modifications », explique Thompson. C'est pourquoi, lorsque le système grandit sans critère, la dette technique s'accumule silencieusement jusqu'à ce que tout changement, même modeste, devienne une opération à risque.
« Supprimer le code, ce n'est pas reculer, mais réduire la surface d'erreur, simplifier l'architecture et laisser le système dans un état où les futures modifications sont plus rapides et plus sûres », ajoute-t-il. Cette opération exige plus de discernement que d'ajouter de la nouvelle fonctionnalité, car elle oblige à comprendre le système en profondeur, à identifier ce qui est vraiment important, mais également à avoir le jugement pour l'ignorer.