Il n'y a pas de limite à quel point le code peut devenir mauvais

Il existe une métaphore persistante pour les bases de code négligées : un navire qui coule. Cela implique une fin éventuelle — un point où l'eau atteint le pont et où tout le monde abandonne. Mais c'est trompeur. Comme le soutient Zach Kehs dans son essai Il n'y a pas de limite à la dégradation du code, contrairement à un navire physique, un système logiciel n'a pas de limite structurelle inhérente. Vous pouvez ajouter de la complexité indéfiniment ; il ne s'effondrera pas. Il deviendra juste plus lent, plus difficile à modifier, et plus pénible à utiliser.

Un exemple concret chez Amazon

Kehs décrit son expérience datant d'une décennie dans une équipe de traitement des commandes chez Amazon. La fonction principale du système — écrire dans une base de données et appeler d'autres services — aurait dû être maintenue par deux douzaines d'ingénieurs. Pourtant, l'organisation comptait des centaines de personnes. Les connaissances institutionnelles se sont érodées à mesure que les ingénieurs partaient, laissant des « cimetières hantés » dans le code. Les règles métier étaient souvent non documentées, et le système s'étendait au-delà des frontières des équipes, rendant le traçage impossible.

Tous les deux ou trois ans, une nouvelle recrue senior tentait une réarchitecture. Cela échouait toujours. Le système était trop complexe pour être compris entièrement, et le cycle de promotion impatient signifiait que les corrections étaient conçues avec des informations incomplètes. Le résultat : de nouvelles couches greffées sur l'architecture, des augmentations d'effectifs qui ne disparaissaient jamais, et le cycle se répétait.

Pourquoi la métaphore ne tient pas

L'idée clé de l'auteur : une entreprise peut couler — mais le logiciel lui-même ne coule pas. Le code peut toujours empirer. Il y a toujours une autre couche d'indirection, une autre dégradation de performance. Mais ironiquement, l'entreprise meurt souvent avant que le code n'atteigne une quelconque « fond ».

Pour les développeurs confrontés à des systèmes hérités, l'enseignement est que le « navire qui coule » donne un faux réconfort. Il n'y a pas de point de non-retour où les choses se réinitialisent magiquement. Si vous êtes dans un tel système, vous n'attendez pas qu'il coule — vous attendez que quelqu'un décide que le coût du changement dépasse le coût du maintien du statu quo.

Lisez l'essai complet pour une réflexion plus approfondie sur les mécanismes de la dette technique dans les grandes organisations.