Nous ne pouvons pas nous arrêter maintenant, car nous avons déjà investi 1x dans ce produit, mais commençons à dépenser 100x plus au fil des ans ! ACTION!
Vous l'avez peut-être déjà entendu, mais Javascript a été écrit en 10 jours. Son adoption a connu une croissance rapide et ils ne voulaient pas introduire de changements radicaux même après quelques années d'utilisation du langage… donc, maintenant le langage a presque 30 ans (rappelez-vous qu'il date de 1995 !) et nous devons encore gérer ces décisions.
Ils savaient dès les premières années de JS qu'il y avait beaucoup de changements qui profiteraient au langage, mais ils ne voulaient pas briser les « innombrables » sites Web de l'époque (il y avait quelques millions de sites Web au total) à l'époque, sans nécessairement utiliser JS !).
Le recul est de 20/20, et ils auraient pu casser JS d'une manière qui ne serait pas ce qu'il est aujourd'hui.
Encore une fois… C'est exactement ce qu'Angular a fait en cassant et en lançant « Angular 2 ». Juste parce que de nombreuses personnes utilisaient Angular, ils savaient qu'il n'était pas durable de continuer avec AngularJS, ils ont donc commencé à l'abandonner progressivement vers Angular2 et Angular s'est amélioré grâce à cela.
Lorsque nous investissons, nous avons envie de « perdre » ou d'« abandonner » en quittant le navire, mais les gens qui peuvent aller plus loin sont ceux qui savent quand abandonner une mauvaise décision (pas nécessairement mauvaise, mais les choses changent avec le temps).
Retour à l'exemple Angular/JS/2. Certaines entreprises utilisent encore AngularJS, même s'il est arrivé en fin de vie et d'autres il y a quelques années. Maintenant, ils doivent le prendre en charge et le corriger eux-mêmes à mesure qu'ils augmentent leur base de code et prennent la décision de s'y tenir de plus en plus douloureuse et plus difficile à changer en raison de tous les investissements qui y sont consacrés.
Bien sûr, de l'autre côté, il y a des gens qui sautent de mode en mode et créent des monstres qui montrent quelle que soit la technologie qui était la plus populaire à chaque moment, certaines qui ont simplement cessé d'être utilisées une fois que les gens ont essayé de commencer à l'utiliser ou cela, d'autres. raison ou autre, vient de mourir et a cessé d'être entretenu.
Vous pensez que vous avez déjà investi « trop », vous ne pouvez donc pas reculer. Vous pensez également que vous n'avez pas besoin des nouvelles choses brillantes si la vieille pile LAMP ennuyeuse est suffisante et fonctionne.
Mais une chose est « ça marche » et une autre est : « à long terme, cela coûtera plus cher que de changer ».
Au sens financier, une nouveauté pourrait vous permettre d'aller plus vite et plus loin, ou du moins, vous laissera libre de poursuivre d'autres opportunités que vous auriez pu manquer autrement.
Les banques fonctionnent en COBOL, cela fait des décennies qu'elles sont en « déclin », mais à chaque fois, elles disent qu'il vaut plus la peine de conserver leur héritage COBOL et d'embaucher des développeurs COBOL à des prix de plus en plus élevés que de travailler à en migrer. TBF, espérons-le, étouffe leur héritage. Mais s'ils développent toujours activement en COBOL, aucun LLM ne les aidera quand il commencera à coûter trop cher pour embaucher des développeurs COBOL sur un marché avec de moins en moins de personnes disponibles.
Pendant ce temps, les nouveaux concurrents sans cet héritage peuvent entrer sur le marché avec d'autres piles qui leur permettent d'évoluer plus rapidement, à moindre coût et avec un plus grand bassin de recrutement disponible.
L'analogie est celle de diriger un énorme navire. Lorsqu’on tourne la barre du navire, le changement n’est pas immédiat. Vous devez vous préparer à l’avance et il existe des stratégies pour faciliter cette tâche. Ensuite, il faudra encore un certain temps avant qu’il soit clair que oui, le navire tourne.
Mais revenons aux analogies financières : ROI (retour sur investissement).
Vous utilisez le retour sur investissement pour calculer quel investissement est le meilleur, en comparant généralement celui que vous évaluez à un investissement « de base ».
Cela signifierait calculer combien de temps est « perdu » en maintenant le statu quo par rapport aux gains estimés du changement proposé. Bien sûr, vous devrez ajouter le temps consacré au changement et avec cela, vous obtiendrez un certain nombre de temps pendant lesquels cela commencerait à vous rapporter des « bénéfices » sur cet investissement.
Si les gains calculés sont si faibles qu'il faudrait beaucoup de temps pour prendre effet, cela n'en vaut peut-être pas la peine.
Celui-ci concernait le temps passé sur une tâche, mais vous pouvez également utiliser d'autres mesures telles que l'accessibilité, la sécurité et la fiabilité… si vous pouvez mesurer quelque chose, cela peut être utilisé pour justifier un changement.
Clause de non-responsabilité: Toutes les ressources fournies proviennent en partie d'Internet. En cas de violation de vos droits d'auteur ou d'autres droits et intérêts, veuillez expliquer les raisons détaillées et fournir une preuve du droit d'auteur ou des droits et intérêts, puis l'envoyer à l'adresse e-mail : [email protected]. Nous nous en occuperons pour vous dans les plus brefs délais.
Copyright© 2022 湘ICP备2022001581号-3