Ce billet de blog explore la stratégie d'utilisation des "boring technologies", c'est-à-dire des technologies maîtrisées mais moins tendance, en les poussant à leurs limites avant de changer. L'auteur, Jérémy DECOOL, souligne l'importance de bien connaître les capacités des outils existants, comme les bases de données relationnelles ou les monolithes, avant d'adopter des solutions plus complexes comme le NoSQL ou les microservices. Il met en garde contre l'anticipation et le marketing, qui peuvent pousser à changer de technologie trop tôt, et insiste sur l'importance de l'expérience et de la connaissance approfondie des outils pour identifier le bon moment pour évoluer.
L’article présente une sélection d’essais influents qui ont marqué la pensée et les pratiques de l’auteur en tant qu’ingénieur logiciel. Parmi les textes cités, on retrouve des classiques comme « Choose Boring Technology » de Dan McKinley, qui prône l’utilisation de technologies éprouvées pour éviter les risques inutiles, « Parse, Don’t Validate » d’Alexis King, qui encourage à transformer les données en types riches pour éliminer les états invalides, ou « Things You Should Never Do, Part I » de Joel Spolsky, mettant en garde contre les réécritures complètes de code. D’autres essais, comme « The Majestic Monolith » de DHH ou « The Rise of ‘Worse is Better’ » de Richard P. Gabriel, remettent en question les tendances architecturales (microservices, perfectionnisme) au profit de solutions pragmatiques et adaptées au contexte. L’auteur souligne aussi l’importance de la qualité (« Software Quality at Top Speed » de Steve McConnell) et de la valeur métier (« Don’t Call Yourself a Programmer » de Patrick McKenzie). Enfin, des conseils plus larges, comme « How To Become a Better Programmer by Not Programming » de Jeff Atwood, rappellent que les compétences techniques ne suffisent pas : comprendre le domaine, communiquer et éviter la complexité inutile sont tout aussi cruciaux. Une lecture inspirante pour repenser sa pratique du développement.