Le problème d'un curseur, c'est forcément que tout le monde ne va pas le mettre au même endroit et qu'il y a une grosse part de sensibilité dans les choix qui seront faits. Que celui qui prétend être objectif prenne un peu de recul, ou regarde 3/4 ans après le résultat de ses choix... et si il n'a pas de doutes, c'est que c'est un crétin aveugle.
Personnellement, je me suis souvent battu contre l'écriture de script en Perl, parce que j'avais personne sous la main pour les maintenir, et que les besoins étaient ultra rudimentaires, donc on privilégiait Shell + AWK. Cette partie, je l'ai rarement regrettée.
Et quand c'était plus compliqué, effectivement on poussait vers java, parce que toute notre équipe codait en java. Parfois, ça s'est avéré être un poison.
Sur les arguments autour du Mainframe, c'est à double tranchant. On repousse continuellement les migrations, mais IBM se goinfre de plus en plus sur les factures. Et trouver de la compétence est de plus en plus dur. Personne ne peut contester la fiabilité du bouzin, mais on se retrouve avec de plus en plus de surcouches. Quelqu'un a essayé de faire communiquer du Mainframe avec autre chose que du transfert de fichier ou du messaging ? De faire du reporting évolué et personnalisable par le end-user ? Du web un peu sérieux ?
Et pourtant, je suis le premier à dire qu'une interface texte, même pour des utilisateurs lambda, et du code backend en Cobol, c'est le truc qui marche pendant 20 ans avec pratiquement que des évolutions fonctionnelles, pas de la maintenance de framework à la mords-moi-le-noeud ou du contournement de bug mystérieux.
Mais tout ça, c'est des détails. Plein de détails, dans un océan de merdes. Une autre merde, c'est que quand on prévoit un budget pour une refonte de plateforme, on prévoit la migration initiale (je vais passer de Cobol à Java/Angular), mais on oublie de prévoir les 2/3 ETPs sur les 20 ans à venir qui ne vont faire que la mise à jour des cadriciels... Du coup, c'est pas fait, et au bout de 3 ans, parfois avant la fin du projet de migration, tu as déjà une pile logicielle obsolète... Et si tu arrives avec 2/3 ETPs, on te retoque en t'expliquant que la plateforme actuelle est très stable, et fonctionne avec moins de personnes... Le chien qui se mord la queue...
Et comme dit par ailleurs, les choix pris "par projet" dans une organisation qui compte des milliers de plateformes, ça va 5 minutes ; la cohérence est également importante au niveau global. Mais ne doit pas empêcher de basculer de techno quand ça a du sens. Sans basculer trop vite pour ne pas se retrouver dans des impasses.
Si quelqu'un a la formule magique, je suis preneur.
# Curseur à géométrie variable
Posté par Dring . En réponse au journal Le sophisme du meilleur outil. Évalué à 5.
Le problème d'un curseur, c'est forcément que tout le monde ne va pas le mettre au même endroit et qu'il y a une grosse part de sensibilité dans les choix qui seront faits. Que celui qui prétend être objectif prenne un peu de recul, ou regarde 3/4 ans après le résultat de ses choix... et si il n'a pas de doutes, c'est que c'est un crétin aveugle.
Personnellement, je me suis souvent battu contre l'écriture de script en Perl, parce que j'avais personne sous la main pour les maintenir, et que les besoins étaient ultra rudimentaires, donc on privilégiait Shell + AWK. Cette partie, je l'ai rarement regrettée.
Et quand c'était plus compliqué, effectivement on poussait vers java, parce que toute notre équipe codait en java. Parfois, ça s'est avéré être un poison.
Sur les arguments autour du Mainframe, c'est à double tranchant. On repousse continuellement les migrations, mais IBM se goinfre de plus en plus sur les factures. Et trouver de la compétence est de plus en plus dur. Personne ne peut contester la fiabilité du bouzin, mais on se retrouve avec de plus en plus de surcouches. Quelqu'un a essayé de faire communiquer du Mainframe avec autre chose que du transfert de fichier ou du messaging ? De faire du reporting évolué et personnalisable par le end-user ? Du web un peu sérieux ?
Et pourtant, je suis le premier à dire qu'une interface texte, même pour des utilisateurs lambda, et du code backend en Cobol, c'est le truc qui marche pendant 20 ans avec pratiquement que des évolutions fonctionnelles, pas de la maintenance de framework à la mords-moi-le-noeud ou du contournement de bug mystérieux.
Mais tout ça, c'est des détails. Plein de détails, dans un océan de merdes. Une autre merde, c'est que quand on prévoit un budget pour une refonte de plateforme, on prévoit la migration initiale (je vais passer de Cobol à Java/Angular), mais on oublie de prévoir les 2/3 ETPs sur les 20 ans à venir qui ne vont faire que la mise à jour des cadriciels... Du coup, c'est pas fait, et au bout de 3 ans, parfois avant la fin du projet de migration, tu as déjà une pile logicielle obsolète... Et si tu arrives avec 2/3 ETPs, on te retoque en t'expliquant que la plateforme actuelle est très stable, et fonctionne avec moins de personnes... Le chien qui se mord la queue...
Et comme dit par ailleurs, les choix pris "par projet" dans une organisation qui compte des milliers de plateformes, ça va 5 minutes ; la cohérence est également importante au niveau global. Mais ne doit pas empêcher de basculer de techno quand ça a du sens. Sans basculer trop vite pour ne pas se retrouver dans des impasses.
Si quelqu'un a la formule magique, je suis preneur.