Discussion :

[Mathis Lucas]

Le développement logiciel moderne est-il essentiellement une source de frais généraux inutiles ? Oui
selon un ancien ingénieur de Google qui ajoute que le secteur est submergé par une complexité inutile

Avery Pennarun, ancien ingénieur de Google et PDG de Tailscale, critique les pratiques modernes de développement de logiciels. Il affirme dans une récente analyse que le développement logiciel moderne est submergé par une complexité inutile et des "frais généraux inutiles". Ce phénomène serait dû à "une focalisation erronée" sur l'évolutivité pour des tâches qui en ont rarement besoin. Il oppose les pratiques de développement actuelles à l'efficacité de la programmation dans les années 90, où des systèmes plus simples pouvaient gérer des charges de travail substantielles rapidement et efficacement sans l'infrastructure gonflée que l'on voit aujourd'hui.

Les pratiques de programmation ont-elles évolué dans le mauvais sens ?

Bien que Avery Pennarun ne l'affirme pas directement, il déplore une perte inquiétante de l'efficacité qui caractérisait le secteur jusqu'à la fin des années 1990 et invite à une profonde réflexion sur le sujet. Ancien ingénieur de Google, Avery Pennarun est aujourd'hui cofondateur et PDG de l'entreprise de logiciels Tailscale basée à Toronto, en Ontario, au Canada. Tailscale développe un réseau privé virtuel maillé défini par logiciel partiellement open source et un service de gestion basé sur le Web. La société propose un VPN sans configuration en tant que service sous le même nom. Pennarun est diplômé de l'université de Waterloo.

Dans un récent billet de blogue publié sur le site Web officiel de Tailscale, Pennarun a fait remarquer qu'il y a 100 fois plus de gens qui peuvent être programmeurs aujourd'hui parce qu'ils ne sont pas coincés avec le C++ et le langage d'assemblage, et beaucoup, beaucoup, beaucoup plus de gens ont maintenant une sorte d'ordinateur. Plus les boutiques d'applications, les systèmes de paiement, les graphiques. « Tout ça, c'est du bon boulot. Mais les choses ont aussi empiré. Beaucoup de choses quotidiennes qui étaient faciles pour les développeurs sont désormais difficiles. C'était inattendu. Je ne m'y attendais pas », a-t-il écrit.

Il ajoute : « je m'attendais à ce que je n'aie plus de travail à l'heure actuelle parce que la programmation était si facile. Au lieu de cela, l'industrie technologique est devenue un véritable fouillis. Et la situation empire au lieu de s'améliorer ! Notre tour de la complexité est maintenant si haute que nous envisageons sérieusement d'y ajouter des grands modèles de langage pour écrire le code incompréhensible dans les cadres incompréhensibles afin que nous n'ayons pas à le faire. Et vous savez, nous, les personnes âgées, sommes celles qui ont le contexte pour voir cela ». Il n'est pas pessimiste et a déclaré que tout est réparable.

Dans son analyse, Pennarun met en cause de nombreuses pratiques modernes, dont la mise à l'échelle et la notation Big O, qui ont complexifié la tâche pour les développeurs au lieu de rendre les choses plus faciles. Il critique l'obsession des programmeurs pour les outils comme Kubernetes pour des tâches triviales, suggérant que de nombreuses pratiques modernes ralentissent les développeurs.

La mise à l'échelle, les conteneurs... que des facteurs de ralentissement ?

Le billet de blogue de Pennarun appelle à une réévaluation des approches actuelles de développement logiciel, préconisant un changement pour rendre les "choses faciles faciles" et réduire la complexité qui entrave la productivité. Il critique sévèrement la notion de mise à l'échelle qui a rendu les programmeurs d'aujourd'hui impatients et les pousse à embrasser des technologies qui leur donnent l'illusion qu'ils sont productifs et efficaces. « Les programmeurs d'aujourd'hui sont impatients de réussir. Ils commencent à planifier pour un milliard d'utilisateurs avant même d'écrire leur première ligne de code », a-t-il déploré.

Il a ajouté : « en fait, de nos jours, nous les entraînons à faire cela sans même savoir qu'ils le font. Tout ce qu'on leur a appris tourne autour de la mise à l'échelle. Nous sommes tombés dans ce piège depuis que les informaticiens ont commencé à enseigner la notation big-O. En notation big O, si vous l'utilisez mal, une table de hachage est censée être plus rapide qu'un tableau, pour pratiquement tout ce que vous voulez faire. En réalité, ce n'est pas toujours le cas. Lorsque vous avez un milliard d'entrées, une table de hachage est peut-être plus rapide. Mais lorsque vous avez 10 entrées, ce n'est presque jamais le cas ».

Mais d'après Pennarun, les gens ont du mal à accepter cette idée. « Ils continuent à choisir les algorithmes et les architectures qui peuvent être mis à l'échelle, même si, en l'absence d'une telle mise à l'échelle, une autre solution serait des milliers de fois plus rapide, et également plus facile à construire et à exécuter », a-t-il déclaré. Il donne cet exemple :

J'ai lu récemment un article dans lequel quelqu'un se vantait d'utiliser Kubernetes pour atteindre 500 000 pages vues par mois. Mais cela représente 0,2 requête par seconde. Je pourrais servir cela à partir de mon téléphone, sur batterie, et il passerait la majeure partie de son temps à dormir.

Dans l'informatique moderne, nous tolérons de longues constructions, puis des constructions de dockers, le téléchargement vers des magasins de conteneurs, des temps de déploiement de plusieurs minutes avant que le programme s'exécute, et des temps encore plus longs avant que la sortie du journal soit téléchargée à un endroit où vous pouvez la voir, tout cela parce que nous avons été trompés dans cette idée que tout doit être mis à l'échelle.

Les gens sont enthousiastes à l'idée de déployer sur le dernier service d'hébergement de conteneurs parce que cela ne prend que quelques dizaines de secondes au lieu de quelques minutes. Mais sur mon ordinateur lent des années 1990, je pouvais exécuter un programme Perl ou Python qui démarrait en quelques millisecondes et servait bien plus que 0,2 requête par seconde, et imprimait les journaux sur Stderr immédiatement pour que je puisse éditer et exécuter le débogage encore et encore, plusieurs fois par minute.

À la question de savoir comment nous en sommes arrivés là, Pennarun a répondu : « nous en sommes arrivés là parce que parfois, quelqu'un a vraiment besoin d'écrire un programme qui doit s'adapter à des milliers ou des millions de back-end, et qui a donc besoin de tous ces... trucs. Et c'est en prenant ses désirs pour des réalités que l'on s'imagine que même le plus petit des tableaux de bord pourrait un jour devenir aussi populaire ».

Toutes les applications modernes ont-elles besoin d'être mises à l'échelle ?

Selon l'ancien ingénieur de Google, la vérité est que la plupart des choses ne sont pas mises à l'échelle et n'ont jamais besoin de l'être. « Même les développeurs des entreprises qui fabriquent des produits pouvant être mis à l'échelle de milliards d'utilisateurs passent la plupart de leur temps sur des choses qui ne le sont pas, comme les tableaux de bord et les générateurs de mèmes. En tant qu'industrie, nous avons passé tout notre temps à rendre les choses difficiles possibles, et pas du tout à rendre les choses faciles », a écrit Pennarun. Selon l'ingénieur, tout ceci ruine la productivité et crée aussi des frais généraux inutiles.

« Les programmeurs sont tous enlisés dans la boue. Il suffit d'écouter n'importe quel développeur professionnel et de lui demander quel pourcentage de son temps est consacré à la résolution du problème qu'il s'est fixé, et quel pourcentage est consacré à des frais généraux inutiles. Lorsque nous explorons le monde de l'hypercomplexité, nous constatons que la plupart des problèmes ne présentent pas de complexité essentielle. En d'autres termes, les problèmes peuvent être résolus sans complexité, mais pour une raison ou une autre, les solutions que nous utilisons sont de toute façon compliquées », a-t-il déclaré.

Il donne l'exemple suivant : « les systèmes de journalisation. Ils se contentent de transmettre du texte d'un endroit à un autre, mais pour une raison ou une autre, il faut 5 minutes pour qu'il apparaisse. Ou les systèmes d'orchestration : ce sont des programmes dont la seule tâche est d'exécuter d'autres programmes, ce que les noyaux Unix font très bien, en quelques millisecondes, depuis des décennies. Les gens superposent des tas de boue. Mais on peut les enlever ».

Dans la communauté, les réactions sont mitigées. De nombreux commentateurs partagent l'avis de Pennarun, affirmant que les programmeurs et les entreprises d'aujourd'hui suivent les mots à la mode ou les tendances qui n'ont parfois aucun rapport avec les produits qu'ils cherchent à développer. « Le secteur est éternellement sensible aux "habitudes des gens efficaces" et se lance la tête première dans l'ingénierie et les promesses de mots à la mode. La plupart du temps, ils cherchent à résoudre un problème qu'ils n'auront jamais en utilisant une technologie qu'ils ne comprennent pas vraiment », a écrit un critique.

Les fournisseurs de cloud profitent de la situation et perçoivent des loyers

Pennarun s'en prend également au rôle prépondérant des entreprises comme AWS (Amazon Web Services) dans la complexification sans cesse croissante du développement logiciel moderne. Il lance un appel à reprendre l'Internet à ces entreprises qu'il appelle : les gardiens centralisés du cloud computing qui perçoivent des loyers.

Pour connaître le goulot d'étranglement d'un système économique donné, il suffit de savoir qui perçoit le loyer. Dans le monde de la technologie, c'est AWS. Bien sûr, Apple est là pour vendre des ordinateurs portables populaires, mais vous pouvez acheter un autre ordinateur portable ou un autre téléphone.

Microsoft était autrefois le gardien de tout, mais il n'y a plus de verrouillage de Windows, à moins que vous ne le choisissiez. Tous ceux qui disaient au début des années 2000 que "le Web est le nouveau système d'exploitation" ont finalement gagné, mais nous avons oublié de nous en réjouir.

Mais la libération n'a pas duré longtemps. Si vous déployez des logiciels, vous payez probablement un loyer à AWS. Pourquoi cela ? L'informatique, n'est-ce pas ? AWS fournit des ressources informatiques évolutives.

C'est ce que l'on pourrait croire. Mais beaucoup de gens vendent des ressources informatiques bien moins chères. Même un MacBook de milieu de gamme peut effectuer 10x ou 100x plus de transactions par seconde sur son SSD qu'un disque local prétendument rapide dans le cloud, parce que les fournisseurs du cloud vendent ce disque à 10 ou 100 personnes à la fois tout en vous le facturant au prix fort. Pourquoi paieriez-vous des frais exorbitants au lieu d'héberger votre site Web critique sur votre MacBook super rapide ?

Selon Pennarun, il est facile de se tromper en pensant que le système global est distribué. Mais tout cela est centralisé chez des fournisseurs de services cloud. « Ce n'est pas nouveau. IBM faisait déjà de l'informatique multicœur et des machines virtuelles dans les années 1960. C'est la même chose aujourd'hui, avec 50 ans de loi de Moore en plus. Nous avons toujours un grand monopole qui peut faire payer un loyer à tout le monde parce qu'il est le gardien de la seule chose qui compte vraiment », a-t-il déclaré.

Le VPN "zero-config" de Tailscale est présenté comme un exemple de simplification des tâches qui ne nécessitent pas une mise à l'échelle importante, soulignant la nécessité de se concentrer sur des projets essentiels et évolutifs uniquement lorsque cela est nécessaire.

Source : billet de blogue

Et vous ?

Quel est votre avis sur le sujet ?
Le développement logiciel moderne est submergé par une complexité inutile ?
Le développement logiciel moderne est-il essentiellement une source de frais généraux inutiles ?
Êtes-vous d'avis que la mise à l'échelle a rendu le développement logiciel beaucoup plus complexe qu'il ne l'était ?
Toutes les applications modernes ont-elles besoin d'être mises à l'échelle ? La mise à l'échelle est-elle importante en informatique ?
Les pratiques de développement actuelles ont-elles perdu l'efficacité qui caractérisait la programmation dans les années 1990 ?
Les pratiques de développement actuelles favorisent-elles l'accumulation de la dette technique ?
Selon vous, comment rendre les logiciels plus faciles à construire et à exécuter ?

Voir aussi

Des développeurs démissionnent pour échapper aux mauvaises pratiques de codage de leurs entreprises, d'après un récent sondage qui pointe la dette technique comme raison de ce choix d'un lot de 51 %

De nombreux développeurs « n'ont pas les connaissances et les compétences essentielles pour développer efficacement des logiciels sécurisés », l'éducation et la formation sont requises, selon la Fondation Linux

Les ingénieurs en logiciel ne sont pas (et ne devraient pas être) des techniciens, car un grand ingénieur en logiciel est celui qui automatise le travail répétitif ou manuel, par Gabriella Gonzalez

[Jules34]

Super billet, intéressant à lire et facilement transposable dans d'autres domaines dans le sens ou l'informatique à pénétrer pleins de domaine pro .

Dans le milieu juridique/compta ou je bosse tout devient pareil. Pourquoi faire simple quand on peut faire compliqué ?

[Rep.Movs]

Mon avis personnel ne diffère pas vraiment du sien:

• Nos outils sont énormes, voire démesurés: que ce soit les langages, les environnements, les bibliothèques, ou les outils, ils ont tous tellement grossis qu'il se chevauchent en termes de fonctionnalités. L'exemple de l'ordonnanceur est très bien choisi: que ce soit Windows ou Unix, un ordonnanceur est intégré depuis 30 ans minimum. Mais chaque outil ajoute le sien!
• Nos technos sont consommatrices de ressources: Faire un soft en Delphi 3, qui permette de gérer des fiches avec des images, produit un programme de moins de 1Mo et a moins de lignes que l'équivalent en HTML+JS (sans compter électron). Inutile de comparer la conso mémoire ou la réactivité Et en Delphi, j'ai appris un langage, et en gros 3 bibliothèque (stockage, affichage, médias) - en HTML+JS, environ 12 langages et bibliothèques
• On fuit le suivi des dépendances: C'est le principe des conteneurs: figer l'outil - on a ici des VM de produits "pro" dont l'éditeur ne met pas à jour la distribution sous-jacente qui a plus de 7 ans. Mais je le comprends: changer cela c'est tout monter de version en cascade...
• Les outils ne sont pas plus efficaces: Les outils sont peu efficaces: on continue à se battre contre des problèmes d'interactions entre les différentes couches. Quand ça devient trop compliqué, quelqu'un invente un nouveau produit qui simplifie le problème pendant 3-4 ans, puis le produit s'étoffe et devient trop compliqué à maintenir, et on recommence. Le problème n'est pas le produit, mais la capacité humaine moyenne à les prendre en main et les maîtriser. Et avec le nombre de produits actuels, c'est encore plus complexe de s'y retrouver.
• C'est dans les vieux pots ... : Java, C# peuvent paraître compliqués. Mais une fois que les gens ont fait du python sur de gros projets, et qu'on leur montre Java et comment les problèmes sont traités en Java, ils comprennent mieux et s'y mettent. Le problème n° 1 d'un outil, c'est sa courbe d'apprentissage et le délai à être opérationnel. L'énorme majorité des outils des années 80/90 ont été pensés, réfléchis et ont eu le temps de mûrir. Les technos phares actuelles comme PH? Python et Javascript ont été poussées sur le marché trop jeunes et immatures - et payent toujours ce manque de base solide.

Petit complément HTML/CSS: Ces technos sont un énorme fatras irréfléchis. Quelques bonnes idées ont pu poindre le bout de leur nez, mais les écueils que l'on avait en HTML4 sont toujours d'actualité (notamment: les formulaires) - les technologies de création de formulaire en mode texte, que ce soit sur AS/400, OpenVMS ou sous DOS étaient meilleures, plus poussées et parfois carrément plus complètes. Sans parler des technos RAD des années 90 en mode graphique qui permettent de faire des GUI en 10 fois moins de temps que HTML/CSS. Bien sûr, React/Flutter comblent largement le gap en termes de fonctionnalités, mais à quel coût ? C'est toute un infra logicielle supplémentaire à mettre en place pour un service rendu qui devrait être intégré à la techno! (exemples de fonctionnalités HTML Forms qui ne sont pas à la hauteur, même face à Superbase je crois bien: l'édition de texte mutliligne, les calendriers intelligents, les choix arborescents, la gestion de liste de milliers de valeurs...)

[forthx]

J'ai pas grand chose a ajouter, ca me rappelle une image :

Ca date un peu mais c'est toujours d'actualité !

[OuftiBoy]

C'est un fait que je constate depuis de nombreuses années (si pas décennies). J'évoque souvent dans les quelques réponses que je post, que le fond du problème est la complexité croissante des environnements de travail, des langages, des couches qu'on rajoute aux nombreuses autres existant déjà. C'est une dévire, selon, qui a plusieurs réponses:

1. La transformation du Web, qui est passé de simple outil de visionnage d'information, en pratiquement un nouvel OS.
2. La "mémoire", qui était rare et chère au débuts de l'informatique n'est plus un problème, mais qui en engendre d'autres:
2.1 Tant les environnements de travails que les logiciels produits deviennent lourd et lent, car on a complètement oublié de réfléchir a comment bien "faire ce que l'on doit faire, et rien d'autres".
2.2 Le Web est un parfait exemple, des "framework" qui sortent tous les 3 jours et que l'on se mets a utiliser en lisant 3 tutos sur "Youtube".
2.3 Puisque la mémoire est "nettement" moins chère qu'à l'époque, on utilise des tonnes et des tonnes d'outils, de librairies, etc..., là où une petite réflexion peut permettre de résoudre un problème en quelques lignes de code.
3. Les anciens, formés "dans le dur", et les pionniers disparaissent peu à peu du métier, et avec eux s'envolent ce soucis du "bien faire", remplacé par le soucis du "vite fait".
4. Rares sont ceux maintenant qui savent encore comprendre ce qui se trouve à la racines de l'informatique. Certains nouveaux développeurs (et ce n'est pas de leur fautes), ne savent même pas la différence entre le "heap" et la "stack".
5. On en arrive a utiliser des choses que l'on ne maîtrise pas, et pour solutionner le problème, on rajoute une couche.
6. La POO, qui est utile dans certains cas, s'est diffusée partout. On se retrouve avec abstraction sur abstraction, et tout devient plus compliqué a comprendre. La POO, c'est bien quand c'est bien utilisé.

Il y a tant d'autres raisons qu'on pourrait écrire un dictionnaire complet.

Dans les années 80 (j'avais 14 ans), j'allumais mon C64, et en 1 sec, je pouvais commencer à programmer (en basic certes), mais ça m'a permis de commencer à réfléchir a comment "faire bien" avec "peu".
Aujourd'hui, il faut 30 secondes pour qu'une machine démarre, lancer un IDE, créer un projet en devant choisir parmi des dizaines d'options, écrire du code alors qu'il y a déjà "sous le capot" des centaines de choses qui se sont passées, etc... ça ne donne pas envie à un gamin de 14 ans.

J'ai crée mon premier programme (on ne disait pas encore "application" à l'époque) en quelques secondes:

10 PRINT "Je suis content d'avoir mon C64."
20 GOTO 10

BàV, et Peace & Love.

[OuftiBoy]

1./ Avant, on cherchais comment résoudre un problème.
2./ Puis on est passé à chercher la solution sur Google, ou StackOverflow.com.
3./ Et maintenant on veut générer du code via une IA.

Résultat, on ne maîtrise plus rien.

Re-BàV. Et comme toujours, Peace & Love.

[marc.collin]

effectivement quand je compare ce qu'on avait fait comme projet final niveau équivalent bts en moins de 5 semaines

• 1 nouvelle application web en asp avec sql server pour gérer une librairie: gestion de membre, gestion de produit, recherche... multilangue, multi devise
• 1 nouvelle application de bureau en access pour faire la même chose

aujourd'hui refaire cela avec angular, react c'est des mois de travail

tout s'est complexifié de l'infra, gestion, développement, méthode de travail.... résultat le chaos report montre que le taux de réussite de projet informatique n'est pas meilleur qu'il y a 25 ans... autour de 30%...

je vois trop souvent l'emploi de la mauvaise techno, mauvaise gestion

plus cela change plus c'est pareil

[i5evangelist]

Pour coder, on voit des environnement de développement de plusieurs Go ?
Les éditeurs (de texte, EDI) essaient de pallier tout ce bazar en se complexifiant de plus en plus.
Quasiment impossible de modifier le truc avec un simple éditeur.
Pour une application web, il faut maîtriser plusieurs langages, le HTML, le CSS, le javascript ... plus par exemple un langage type PHP par exemple (et d'autres certainement, je ne suis pas expert), bref, je plains les codeurs qui doivent reprendre le support d'une appli écrite par un autre, ça doit être éprouvant.
Le pire, ce doit être les changements de version, avec des langages qui n'assurent pas la compatibilité avec l'ancienne release

Ceci dit, je suis un ancien, place aux jeunes, nos technos sont sûrement ringarde

[totolehero777]

Beaucoup veulent utiliser les choses un peu "tendance" même si cela n'est pas nécessaire et n'apporte rien dans le contexte de leur application...

Par ex, avant de faire de la mise à l'échelle horizontale, on devrait d'abord chercher à faire des optimisations simples.

Passer énormément de temps à faire des choses avancées dans l'intégration continue, implémenter des tests unitaires et d'intégrations en n'en plus finir, alors que souvent, tester manuellement l'application permet de voir des bugs qui ne provoquent pas d'alertes dans les tests automatiques...

Il faut un juste milieu et ne pas faire des choses inutiles, juste parce que en théorie c'est bien de les faire.

Il faudrait un peu revenir à l'essentiel, on code pour implémenter des fonctionnalités qui doivent apporter un plus aux utilisateurs, résoudre un problème concret... et souvent ça peut être fait de manière simple et efficace, sans fioritures, sans sacrifier la réutilisabilité, la maintenabilité et les performances.

[Jitou]

J'ai vu passer 30 ans d'évolution et je constate également comment on est devenu terriblement inefficace !

1. Les devops n'ont plus aucune notion élémentaire de programmation, copilote est leur ami, le code est devenu un patchwork de recettes inefficaces et inmaintenables, mais ça marche pour des clients qui sont prêts à payer des sommes considérables pour juste maintenir le château de carte debout ...

2. Les outils de compilation et de déploiement freinent considérablement les livraisons au point qu'il est nécessaire d'avoir un devops à plein temps sur une équipe de 3 devs pour gérer cette complexité qui n'existait pas auparavant lorsque les dev étaient encore autonomes.

3. Les plateformes d'hébergement d'application, Kubernetes, AWS et autres clouds sont des systèmes ingérables et souvent défaillants, de plus on est obligé d'adapter nos applications à leur fonctionnement alors que ce devrait être l'inverse, sachant que ces environnements sont des gouffres énergétique, un comble lorsque les clients vantent leur étiquette "Green" par ailleurs.

4. L'infra as code tuera définitivement l'informatique, c'est une chimère inventée par des managers qui veulent se faire mouser mais qui n'a aucun fondement technique, d'ailleurs il n'y a pas de "code" la dedans.

5. Les jeunes arrivants ne réfléchissent plus sur ce qu'ils font, ils codent avant de se poser les bonnes questions, mais ce n'est pas grave car ils ne portent aucune responsabilité et si le projet va mal ils cherchent à partir dans l'heure qui suit.

Hier je me suis posé et j'ai tenté d'évaluer le temps passé sur 4 sprints, en moyenne :

1% - design de solution
14% - developpement et corrections de bugs
10% - réunions
75% - devops et résolution de pb de CI / CD ou de Run

Je pense que je n'apprends à personne que les utilisateurs finaux sont les dindons de cette gigantesque farce ...

[electroremy]

Je rejoint les commentaires précédents

J'ai connu l'époque où les ordinateurs étaient peu puissants et chez, j'ai débuté sur Amiga 1200

Jusqu'à la fin des années 1990, on sentait clairement la limite du matériel... l'optimisation d'un algorithme, puis de son implémentation, était des étapes essentielles.
Il fallait économiser la mémoire et en même temps optimiser la vitesse du code... deux enjeux parfois antagonistes, il fallait trouver le bon compromis.
C'est quelque chose qui s'est perdu.

Le plus frustrant c'est que malgrès les ordinateurs très puissants dont on dispose aujourd'hui, ça "rame" toujours autant.
Beaucoups de logiciels actuels ne font pas mieux que leurs anciennes versions, tout en occupant beaucoup plus d'espace disque et en consommant plus de mémoire et de CPU.
Qu'est-ce qu'on fait vraiement de plus avec les versions actuelles de Word et Excel par rapport à celles de 1997 ?
Pas grand chose !
Mais la taille des fichiers d'installation, la capacité CPU et la mémoire requise ont explosées...

Je continue à garder précieusement pas mal d'anciens logiciels (qui ont parfois 20 ou 30 ans) et que j'arrive encore à faire fonctionner aujourd'hui.

Dernier aspect des choses, certainement le pire : la mode des logiciels avec license annuelle en "location".
Une fois que l'éditeur aura débranché le serveur de license, ces logiciels seront inutilisables, laissant sur le carreau toute la communauté d'utilisateurs

Alors qu'avec les anciens logiciels, les licenses étaient perpétuelles.

Dans certains domaines, il arrive même que d'anciens logiciels fassent mieux que ceux d'aujourd'hui !

Seul espoir : le succès de l'embarqué, qui oblige les jeunes générations d'aujourd'hui à retrouver les bons et anciens reflexes de l'optimisation...
Mais là aussi, le matériel évolue, et même des petits microcontrôleurs arrivent à être aussi voire plus puissants que les ordinateurs d'il y a 30 ans.

[Montaigne]

Un autre aspect du problème est que les gens apprennent à concevoir une application selon un modèle (genre Java avec couche data/services whatever) et pensent - et c'est massif dans l'industrie- qu'on doit forcément écrire une appli comme ça.

J'ai une anecdote à ce sujet. J'avais écris une appli qui avait une archi un peu particulière : beaucoup de SQL très barbu qui crachait du JSON. Une appli Java faisait passe plat entre la couche web et Postgres (c'était dans PostgRest). En gros, il y avait 3 point d'appels différents en tout et pour tout
Un jeune a repris mon appli : il a tout refait avec des couches data/services whatever, l'appli était devenu inutilement complexe pour rien.

Je ne parle même pas de l'idiotie de faire une classe pour représenter une requête : MonObjetMachinById, MonChienByName, MonFormagePrefereByRegion. On a inventé une sémantique pour faire des requête et on créé des milliers de classes avec des interactions dans tous les sens, des frameworks pour garder un couplage "lâche" (suivez mon regard), à cause d'un problème qu'on a artificiellement créé.

Les jeunes que je forme en école ont une vision assez consternante du code, pour eux, il s'agit juste de raccorder des tuyaux entre eux. Ils sont d'ailleurs très fort avec les frameworks "automagiques", ils jonglent avec une dextérité dingue, mais quand il s'agit d'écrire un algo, ya plus grand monde...
L'IA vient pour enfoncer le clou dans le cercueil : ça va pas s'arranger, on va générer automatiquement le raccordement de tuyaux entre eux.

Concevoir une archi spécialement adapté au problème, ça demande de la créativité, d'oser sortir des modèles pré-établis et un recul aussi bien technique que théorique. Et le problème, c'est que la majorité des écoles "Bac+5" en informatique, forme des supertechniciens qui n'ont aucune connaissance théorique ("La turing-completness, ça se mange ?"), peu de culture technique, et résultat, ça produit des usines à gaz.

[Bigb]

L'auteur a mille fois raison !
On nous vend aujourd'hui de la simplicité plus complexe qu'auparavant.
Pour une boite avec un seul site sur le marché FR quel intéret de passer par AWS ? Un serveur dédié coute 10x moins cher et est 100x plus puissant.

Je me rappelle le premier passage télé de notre site, il y a 15 ans, tout avait explosé et le site n'arrivait absolument pas à tenir la charge. Aujourd'hui n'importe uel serveur peut encaisser des milliers d'accès et une couche cloudflare rend la problématique inutile.