Simple ≠ petit : repenser la complexité logicielle
Original : Simple Is Not Small
Pourquoi c'est important
Cette distinction oriente la conception d'architectures logicielles plus maintenables et robustes.
Un article de jyn.dev (publié le 27 août 2026) remet en question l'équation courante entre « simple » et « petit » en développement logiciel, en s'appuyant sur des exemples concrets de pipelines Unix et de code Clojure pour distinguer taille et couplage.
L'auteur part d'une question posée après sa conférence sur la couverture de code : comment construire des outils pour éviter des bugs épiques ? Sa réponse — « prioriser la simplicité » — l'insatisfait, et l'article en explore les raisons. Il illustre son propos avec deux programmes calculant la fréquence des mots d'un fichier : un pipeline Unix (cat, tr, sort, uniq) et son équivalent Clojure. Le pipeline Unix est petit et concis, mais lorsqu'on veut afficher les mots dans l'ordre d'apparition original, le code Bash devient un enchevêtrement illisible de fichiers temporaires, regex et jointures. En Clojure, la modification reste claire et directe. L'auteur s'appuie sur la définition de Rich Hickey dans « Simple Made Easy » : « simple » vient de « sim-plex » (une seule tresse), par opposition à « com-plex » (plusieurs tresses entrelacées, soit le couplage). Conclusion : un programme peut être petit sans être simple, et grand sans être couplé. La véritable simplicité réside dans le découplage des responsabilités, pas dans la réduction du volume de code.