Un ing�nieur affirme que le d�veloppement logiciel moderne est une source de frais g�n�raux inutiles

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 :

Envoy� par Avery Pennarun

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.

Envoy� par Avery Pennarun

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

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� ?

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...)

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

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

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.

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.

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

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

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.

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 ...

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.

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.

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.