J'ai l'impression qu'on cadre beaucoup cette discussion comme si c'était (uniquement) un problème de compétence des développeurs. Je pense que ce n'est pas vraiment le cas, il y a plein d'autres choses qui rentrent en jeu.
La première, c'est que dans beaucoup de cas, les optimisations ne sont pas nécessaires ou pas prioritaires. Optimiser le code, concevoir l'architecture la plus efficace, ça prend du temps. Souvent, c'est plus important de livrer des nouvelles fonctionnalités très vite (avant les concurrents). Et en plus, on travaille avec des spécifications changeantes (les fameuses méthodes agiles), alors que pour faire de l'optimisation, il faut souvent pouvoir considérer un problème dans son intégralité pour bien déterminer la solution optimale. Si tu passes un mois à écrire la structure de donnée parfaite, mais que la semaine suivante, finalement ton programme doit faire autre chose, tu peux tout jeter et recommencer.
Il y a aussi une certaine tolérance des utilisateurs. C'est vrai en informatique mais aussi dans d'autres domaines. Par exemple, les téléphones mobiles modernes ont une latence plus importante que les anciens téléphones fixes à réseau par commutation de circuits. On s'est habitué, les usages ont évolué, et maintenant on arrive même à faire des visioconférences à plusieurs avec une latence encore plus importante. Il en va de même pour l'informatique, les gens développent une tolérance aux interfaces lentes et on peut se permettre d'être de pire en pire sans que ça fasse fuir tous les clients.
Du côté des développeurs, par contre, il y a quelques domaines où ça ne marche pas comme ça: le jeu vidéo, ou les systèmes embarqués/temps réel par exemple. Dans ces contextes là, il y a moins de problème pour passer du temps à optimiser les choses, il y a le budget pour, parce que sinon, le projet de marche pas.
Une solution serait de rendre les choses obligatoires. Pour la sécurité ça commence à se faire par exemple avec le Cyber Resilience Act qui va pousser les entreprises à assurer les mises à jour de sécurité. Du côté des performances, il pourrait y avoir des équivalents pour l'éco-conception (soit avec des obligations, soit avec un étiquettage/certification de type "nutri score"). En fait, c'est aussi déjà le cas dans certains domaines, les développeurs de frigo connectés sont très bons pour faire de l'électronique et du logiciel à basse consommation pour pouvoir afficher le score A++ en consommation d'énergie.
Au final, le problème ce n'est pas vraiment les développeurs, ce sont les clients qui ne veulent pas payer pour avoir des logiciels performants, ils préfèrent avoir un truc moins cher et livré plus tôt, et payer un peu plus de matériel. Là, une autre solution serait de rééquilibrer le coût du matériel (vraiment pas cher actuellement) et le coût du travail humain. Si les développeurs étaient payés moins cher, on pourrait leur faire passer du temps pour faire des économies sur le matériel. Ce n'est clairement pas l'équilibre actuel des choses.
[^] # à qui la faute?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Software is Way Less Performant Today. Évalué à 7.
J'ai l'impression qu'on cadre beaucoup cette discussion comme si c'était (uniquement) un problème de compétence des développeurs. Je pense que ce n'est pas vraiment le cas, il y a plein d'autres choses qui rentrent en jeu.
La première, c'est que dans beaucoup de cas, les optimisations ne sont pas nécessaires ou pas prioritaires. Optimiser le code, concevoir l'architecture la plus efficace, ça prend du temps. Souvent, c'est plus important de livrer des nouvelles fonctionnalités très vite (avant les concurrents). Et en plus, on travaille avec des spécifications changeantes (les fameuses méthodes agiles), alors que pour faire de l'optimisation, il faut souvent pouvoir considérer un problème dans son intégralité pour bien déterminer la solution optimale. Si tu passes un mois à écrire la structure de donnée parfaite, mais que la semaine suivante, finalement ton programme doit faire autre chose, tu peux tout jeter et recommencer.
Il y a aussi une certaine tolérance des utilisateurs. C'est vrai en informatique mais aussi dans d'autres domaines. Par exemple, les téléphones mobiles modernes ont une latence plus importante que les anciens téléphones fixes à réseau par commutation de circuits. On s'est habitué, les usages ont évolué, et maintenant on arrive même à faire des visioconférences à plusieurs avec une latence encore plus importante. Il en va de même pour l'informatique, les gens développent une tolérance aux interfaces lentes et on peut se permettre d'être de pire en pire sans que ça fasse fuir tous les clients.
Du côté des développeurs, par contre, il y a quelques domaines où ça ne marche pas comme ça: le jeu vidéo, ou les systèmes embarqués/temps réel par exemple. Dans ces contextes là, il y a moins de problème pour passer du temps à optimiser les choses, il y a le budget pour, parce que sinon, le projet de marche pas.
Une solution serait de rendre les choses obligatoires. Pour la sécurité ça commence à se faire par exemple avec le Cyber Resilience Act qui va pousser les entreprises à assurer les mises à jour de sécurité. Du côté des performances, il pourrait y avoir des équivalents pour l'éco-conception (soit avec des obligations, soit avec un étiquettage/certification de type "nutri score"). En fait, c'est aussi déjà le cas dans certains domaines, les développeurs de frigo connectés sont très bons pour faire de l'électronique et du logiciel à basse consommation pour pouvoir afficher le score A++ en consommation d'énergie.
Au final, le problème ce n'est pas vraiment les développeurs, ce sont les clients qui ne veulent pas payer pour avoir des logiciels performants, ils préfèrent avoir un truc moins cher et livré plus tôt, et payer un peu plus de matériel. Là, une autre solution serait de rééquilibrer le coût du matériel (vraiment pas cher actuellement) et le coût du travail humain. Si les développeurs étaient payés moins cher, on pourrait leur faire passer du temps pour faire des économies sur le matériel. Ce n'est clairement pas l'équilibre actuel des choses.