Le choix d’une solution « tournée vers le futur et prenant en compte des besoins non encore exprimés mais qui à coup sûr ne manqueront pas de survenir, tout en minimisant le risque de créer de la dette technique » plutôt qu’une solution « ad-hoc, minimale et sans la moindre de nouveauté par rapport aux solutions déjà mises en œuvre par ailleurs » me laisse toujours songeur quant aux attentes de ses promoteurs.
Pour prendre un exemple (à peine fictif) que je trouve représentatif : un besoin qui pourrait être adressé à l’aide d’un simple script shell/Perl qui fait deux requêtes SQL et trois appels API, va sembler à certains être une bonne occasion de mettre en œuvre un flux de messages (parce qu’ajouter un SPOF est toujours bon è prendre ?), choisir d’implémenter cela en Go (parce qu’en 202X le shell/Perl est obsolète ?) quand bien même il sait parfaitement que bien que le Go puisse être plus facile à maintenir que le shell dans l’absolue, il n’est dans le contexte maîtrisé que par deux personnes dont une part à la retraite dans un an. Sans oublier de mettre en place une chaîne de CI exprès pour ce « projet », en prétextant qu’elle pourra servir pour les futurs outils qu’enfin grâce à lui auront un pied dans l’avenir au lieu de reposer sur des technologies « obsolètes » puisque dépréciées par Google ou Amazon il y a déjà six long mois ! Le fait que telle ou telle brique logiciel n’existe qu’en version 0.X et ait deux chances sur trois d’être abandonnée au profit du nouvel outil « qui fait l’unanimité chez les spécialistes et rend caduc l’intégralité des méthodes mises en œuvre ces cinquante dernières années » n’est pas une source de questionnement mais au contraire le signe indiscutable de la pertinence de leur choix. sans oublier pour finir de déployer ça sur une une plateforme Kubernetes, pas qu’un besoin identifié l’exige, mais parce, mais parce qu’ « Aujourd’hui Kubernetes rend toutes les solutions actuelles obsolètes.
Je peux admettre que je suis probablement touché par un excès inverse, et que je suis amené de ce fait à négliger des solutions réellement avantageuses pour tous à moyen terme. Mais je constate régulièrement que les promoteurs des solutions que j’évoque semblent considérer que la « modernité » elle-même est un argument indiscutable qui valide leur choix en rendant tous les autres choix caducs par principe.
Jeune j’étais persuadé que les « vieux cons » pouvaient parfois avoir raison, maintenant que j’ai ce rôle je suis au moins heureux de découvrir que j’aurais eût tort de penser autrement à l’époque.
# De la pertinence du KISS et d l’anticipation des besoins futurs
Posté par Marotte ⛧ . En réponse au journal Le sophisme du meilleur outil. Évalué à 10.
Je ne suis pas développeur mais devops.
Le choix d’une solution « tournée vers le futur et prenant en compte des besoins non encore exprimés mais qui à coup sûr ne manqueront pas de survenir, tout en minimisant le risque de créer de la dette technique » plutôt qu’une solution « ad-hoc, minimale et sans la moindre de nouveauté par rapport aux solutions déjà mises en œuvre par ailleurs » me laisse toujours songeur quant aux attentes de ses promoteurs.
Pour prendre un exemple (à peine fictif) que je trouve représentatif : un besoin qui pourrait être adressé à l’aide d’un simple script shell/Perl qui fait deux requêtes SQL et trois appels API, va sembler à certains être une bonne occasion de mettre en œuvre un flux de messages (parce qu’ajouter un SPOF est toujours bon è prendre ?), choisir d’implémenter cela en Go (parce qu’en 202X le shell/Perl est obsolète ?) quand bien même il sait parfaitement que bien que le Go puisse être plus facile à maintenir que le shell dans l’absolue, il n’est dans le contexte maîtrisé que par deux personnes dont une part à la retraite dans un an. Sans oublier de mettre en place une chaîne de CI exprès pour ce « projet », en prétextant qu’elle pourra servir pour les futurs outils qu’enfin grâce à lui auront un pied dans l’avenir au lieu de reposer sur des technologies « obsolètes » puisque dépréciées par Google ou Amazon il y a déjà six long mois ! Le fait que telle ou telle brique logiciel n’existe qu’en version 0.X et ait deux chances sur trois d’être abandonnée au profit du nouvel outil « qui fait l’unanimité chez les spécialistes et rend caduc l’intégralité des méthodes mises en œuvre ces cinquante dernières années » n’est pas une source de questionnement mais au contraire le signe indiscutable de la pertinence de leur choix. sans oublier pour finir de déployer ça sur une une plateforme Kubernetes, pas qu’un besoin identifié l’exige, mais parce, mais parce qu’ « Aujourd’hui Kubernetes rend toutes les solutions actuelles obsolètes.
Je peux admettre que je suis probablement touché par un excès inverse, et que je suis amené de ce fait à négliger des solutions réellement avantageuses pour tous à moyen terme. Mais je constate régulièrement que les promoteurs des solutions que j’évoque semblent considérer que la « modernité » elle-même est un argument indiscutable qui valide leur choix en rendant tous les autres choix caducs par principe.
Jeune j’étais persuadé que les « vieux cons » pouvaient parfois avoir raison, maintenant que j’ai ce rôle je suis au moins heureux de découvrir que j’aurais eût tort de penser autrement à l’époque.