Le désenchantement du logiciel
(tonsky.me)- Le logiciel moderne a souvent normalisé l’inefficacité en partant du principe que « les ordinateurs sont assez rapides », au lieu de convertir les progrès du matériel en efficacité, simplicité et niveau de finition
- Même des tâches de base paraissent plus lentes qu’attendu : défilement web, 13 secondes pour ouvrir un e-mail dans Google Inbox, 30 minutes pour une mise à jour de Windows 10, latence de saisie dans les éditeurs de texte
- Android à 6 Go, Windows 10 à 4 Go, Google Keyboard à 150 Mo, les apps Electron et le cas Slack montrent que le gonflement des apps et des plateformes se paie en performances, complexité et fiabilité
- Comme avec les mises à jour d’OS, d’apps et de navigateurs, ou l’abandon par iOS 11 de la prise en charge des apps 32 bits, un logiciel qui fonctionnait bien peut ralentir ou se casser avec le temps
- Pour créer de meilleurs logiciels, les ingénieurs doivent comprendre les performances, la structure et les limites des systèmes qu’ils construisent, et produire des résultats rapides et prévisibles avec moins de ressources
Des logiciels qui gaspillent les performances
- On accepte souvent qu’un logiciel moderne s’exécute à 1 % ou 0,01 % des performances possibles
- Les voitures, les bâtiments et les avions tendent vers leurs limites physiques ou vers des formes optimales, tandis que le logiciel justifie son inefficacité par l’idée que « les ordinateurs sont assez rapides »
- L’adage « le temps du programmeur coûte plus cher que le temps de l’ordinateur » peut masquer une réalité où le temps machine est gaspillé comme jamais
- Un tweet racontant la réécriture en Rust d’un programme Python exécuté chaque jour, passé de 1,5 seconde à 0,06 seconde, mais où il faudrait plus de 41 ans pour compenser les 6 heures investies, est souvent cité comme exemple emblématique du débat sur l’efficacité
Des expériences de base d’une lenteur insupportable
- Les ordinateurs portables modernes sont des milliers de fois plus puissants que ceux de l’époque de l’alunissage, mais même sur un MacBook Pro récent, il est difficile de faire défiler une page web de manière fluide à 60 fps
- Inbox, créé par Google, met 13 secondes à ouvrir un e-mail dans Google Chrome
- Le fait d’animer un rectangle blanc vide au lieu du contenu ressemble davantage à un compromis dicté par les limites de performance d’une page web
- Même à l’époque où les écrans 120 Hz se généralisent, l’auteur estime qu’afficher une seule réponse d’une communauté web n’est même pas stable à 60 Hz
- Une mise à jour de Windows 10 prend 30 minutes, un délai pendant lequel on pourrait, selon la comparaison, formater un SSD puis télécharger et installer une nouvelle build plusieurs fois
- Les éditeurs de texte modernes ont une latence de saisie supérieure à celle d’Emacs, vieux de 42 ans
- Il souligne que même une tâche consistant seulement à mettre à jour une petite zone rectangulaire à chaque frappe ne parvient pas à s’exécuter en moins de 16 ms
- Dans les mêmes 16 ms, les jeux 3D effectuent le rendu de tout l’écran, traitent les entrées, calculent le monde et gèrent les ressources
- Le matériel plus rapide sert désormais moins à faire tourner de meilleurs logiciels qu’à exécuter plus lentement des logiciels qui font la même chose
Apps et plateformes devenues obèses
- Les apps web peuvent devenir 10 fois plus rapides simplement en bloquant les publicités, et AMP ressemble moins à une nouvelle technologie qu’à une solution de bon sens consistant à retirer ce qui est en trop
- Le système Android pèse 6 Go sans aucune app, Windows 95 faisait 30 Mo et Windows 10 fait 4 Go
- Windows 10 est 133 fois plus volumineux que Windows 95, alors que ses fonctions de base ne sont pas fondamentalement différentes
- Android est même 1,5 fois plus gros que Windows 10
- Google Keyboard occupe généralement 150 Mo, l’app Google 350 Mo et Google Play Services 300 Mo
- La critique demande si Google Keyboard, une app qui dessine trente touches à l’écran, est vraiment cinq fois plus complexe que Windows 95 tout entier
- Google Play Services ne peut pas être supprimé même lorsqu’on ne l’utilise pas
- Le fait qu’il ne reste qu’environ 1 Go pour stocker des photos après l’installation des apps par défaut contraste avec l’époque où un système d’exploitation, des apps et des données tenaient tous sur des disquettes
- Une app de todo basée sur Electron peut embarquer des pilotes de manette Xbox 360, du rendu graphique 3D, de la lecture musicale et même la prise de vue par webcam
- Slack est une app proche d’un chat avec un simple éditeur de texte, mais elle est classée parmi les apps lourdes à cause de sa vitesse de chargement et de sa consommation mémoire
- Plus les apps grossissent, plus augmentent la perte de contrôle, le coût de complexité, la perte de performance et la dette de fiabilité ; il ne faut pas accepter comme normales des apps excessivement lourdes
Des logiciels qui pourrissent avec le temps
- Il y a trois ans, un téléphone Android de 16 Go suffisait, mais à l’époque d’Android 8.1, les apps sont devenues deux fois plus grosses sans raison particulière, au point de rendre l’usage difficile
- L’iPhone 4s a été annoncé avec iOS 5, mais il peine à faire tourner iOS 9, sans qu’iOS 9 soit fondamentalement bien supérieur
- iOS 11 a abandonné la prise en charge des apps 32 bits, si bien que des apps sans développeur ou non mises à jour peuvent devenir impossibles à revoir
- Un tweet cité observe que des programmes DOS tournent sans modification sur plusieurs ordinateurs depuis les années 1980, alors qu’une app JavaScript peut casser dès la prochaine mise à jour de Chrome
- Une page web qui fonctionne parfaitement aujourd’hui pourrait ne plus fonctionner correctement dans aucun navigateur d’ici 10 ans
- On achète un nouveau téléphone et un nouveau MacBook pour faire les mêmes choses, mais on finit encore et encore par exécuter les mêmes apps plus lentement
Des attentes de qualité revues à la baisse
- Quand une page web a un problème, elle demande de rafraîchir plutôt que d’en examiner la cause
- Les apps web peuvent produire des erreurs JavaScript « aléatoires » même dans des navigateurs compatibles
- La conception des pages web et des bases de données SQL est critiquée comme reposant sur l’espoir que les données ne changent pas pendant l’affichage d’une page rendue
- Les fonctions de collaboration restent souvent au niveau du « best effort » et intègrent des scénarios quotidiens où des données peuvent être perdues
- Une boîte de dialogue comme « quelle version voulez-vous conserver ? » revient presque à demander laquelle de vos productions doit être détruite
- Linux est l’OS le plus populaire sur les serveurs, bien qu’il soit conçu de façon à pouvoir tuer arbitrairement des processus
- Les exemples des écrans Dell, d’AirDrop et du Bluetooth montrent que les logiciels embarqués dans les appareils et des spécifications complexes créent des expériences dépendantes de redémarrages périodiques ou de la chance
- Pour livrer quelque chose qui fonctionne de manière fiable, il faut comprendre de fond en comble ce que l’on a construit, ce qui devient difficile dans des systèmes démesurément gonflés
Confusion dans les outils de programmation et les pratiques de développement
- Même dans des éléments fondamentaux comme la gestion de packages, les systèmes de build, les compilateurs, la conception des langages ou les IDE, il est difficile de voir un niveau de finition rapide, efficace et durable
- Les systèmes de build disposent de toutes les informations de changement, mais demandent régulièrement de tout supprimer et de recommencer
- L’auteur estime qu’il n’y a aucune raison pour qu’ils ne puissent pas être fiables, prévisibles et reproductibles
- NPM est décrit comme étant resté pendant des années dans un état où il « fonctionne parfois »
- Un tweet cité dit que
rm -rf node_modulessemble inévitable dans le développement Node.js/JavaScript
- Le fait d’accepter que les compilateurs et les tâches avant/après prennent des minutes, voire des heures, entre en contradiction avec l’idée que « le temps du programmeur est important »
- Le choix de Hadoop même lorsqu’il est plus lent que l’exécution sur un seul PC montre que les programmeurs ne prennent pas toujours des décisions rationnelles
- Le machine learning et « l’intelligence artificielle » sont critiqués pour avoir fait entrer le logiciel dans une ère de suppositions peu fiables
- Un tweet cité explique que lorsqu’une app ou un service mentionne « intelligence artificielle » ou « machine learning », il faut lire : peu fiable, imprévisible et difficile à expliquer
- Empiler une VM sur Linux, puis Docker dans cette VM, est interprété comme le signe qu’on ne sait pas ranger proprement programmes, langages et environnements d’exécution
- Le fait que le binaire unique de Go soit considéré comme un avantage majeur révèle une situation où il suffit de ne pas être chaotique pour être perçu comme réussi
- Les dépendances, en voulant résoudre un problème simple avec une « solution packagée complète », apportent à la fois des coûts d’adoption et d’autres dépendances
- Il est difficile d’utiliser un programme pendant des années sans redémarrage, parfois même pendant quelques jours
- Redémarrer des processus, relancer des bases de données, utiliser un watchdog qui redémarre une app toutes les 20 minutes, inclure des ressources en double et les envoyer compressées sont des façons de passer rapidement à autre chose au lieu de corriger
- Ces pratiques relèvent non pas de l’ingénierie, mais de la programmation paresseuse ; l’ingénierie consiste à comprendre en profondeur les performances, la structure et les limites de ce que l’on construit
Complexité accumulée et indifférence du marché
- Le logiciel actuel est un empilement de code qui fonctionne tant bien que mal sur du code qui fonctionne tant bien que mal, et il ne cesse de grossir et de se complexifier, réduisant les occasions de le transformer
- Dans un écosystème sain, il faut parfois reculer pour avancer, mais l’auteur souligne que nous n’avons pas vu de nouveau noyau d’OS depuis 25 ans et qu’il est désormais trop complexe de tout réécrire
- Même pour les navigateurs, les cas limites et les problèmes historiques rendent difficile de réécrire un moteur de mise en page depuis zéro
- Les progrès actuels ressemblent à l’ajout de combustible sur le feu : introduire des microservices pour résoudre les problèmes de monolithes, Docker pour résoudre ceux des microservices, puis Kubernetes pour résoudre ceux de Docker
- Un tweet cité rappelle que nous sommes passés de configurations déclaratives en XML à des configurations de microservices en YAML, mais que le XML avait au moins des schémas
- Les utilisateurs n’ont guère d’autre choix que d’accepter ce que les ingénieurs leur fournissent, même face à des apps Android de 350 Mo, des défilements saccadés ou des situations où il faut « redémarrer si ça ne marche pas »
- Si les produits concurrents sont tous lents, volumineux et de mauvaise qualité, la pression concurrentielle a du mal à apparaître
- Des produits comme l’iPhone/iOS face aux autres smartphones, ou Chrome face aux autres navigateurs, ont parfois créé une tension, mais elle ne dure pas
- La mission des ingénieurs devrait être de montrer ce que les ordinateurs modernes rendent possible en matière de performances, de fiabilité, de qualité et de disponibilité
Des alternatives malgré tout visibles
- Le LMAX Disruptor, SBE et Aeron de Martin Thompson sont cités comme des exemples impressionnants, simples et efficaces
- Le Xi editor de Raph Levien est considéré comme conçu avec les bons principes en tête
- Jonathan Blow a créé un langage pour son propre jeu, et son ordinateur portable peut compiler entièrement à neuf 500 000 lignes de code en une seconde
- Il s’agit bien d’une compilation complète à neuf, et non d’un build incrémental ou d’un cache intermédiaire
- Écrire des programmes rapides ne demande ni génie ni magie ; il suffit, selon l’auteur, de ne pas les construire au-dessus d’un immense tas d’ordures comme les toolchains à la mode
Exigences pour de meilleurs logiciels
- Le génie logiciel ne doit pas rester dans son état actuel : il doit progresser, et il n’est pas nécessaire de refaire les mêmes choses sous des formes plus lentes et plus grosses
- Le développement d’aujourd’hui ressemble moins à un progrès qu’à la satisfaction laborieuse d’objectifs business sur des outils déglingués
- L’auteur estime que, piégés par l’optimisation locale, nous nous sommes habitués à un état obèse et inefficace
- Les ingénieurs peuvent, et doivent, créer avec de meilleurs outils de meilleures apps, avec plusieurs fois moins de ressources, rapidement, de manière prévisible et fiable
- Pour livrer des produits fiables, prévisibles et de grande qualité, il faut comprendre complètement ce que l’on fait et pourquoi ; l’excuse « c’est comme ça qu’on nous l’a donné » n’est pas acceptable
2 commentaires
Une traduction coréenne de cet article a déjà été publiée auparavant, vous pouvez donc la consulter.
https://tonsky.me/blog/disenchantment/ko/
J’ai carrément remplacé cela par le lien vers la traduction.
Avis sur Hacker News
Un code plus petit, plus propre, moins bogué, plus sûr, plus rapide et plus durable est évidemment possible. Si on y arrivait aux débuts de l’ère informatique, il n’y a aucune raison de ne pas y arriver aujourd’hui, avec des décennies d’expérience et des outils puissants.
Si on ne le fait pas, c’est parce qu’il n’y a pas d’argent à en tirer ; en réalité, c’est même presque l’inverse. Les startups financées par le capital-risque doivent arriver les premières sur le marché pour survivre, et même dans les organisations matures, les coûts et l’embonpoint ne sont pas des problèmes, mais fonctionnent comme un moyen d’accroître le prestige des managers. Au final, les coûts sont répercutés sur les clients.
Si les « lois impitoyables du marché » ne corrigent pas ce gaspillage, c’est sans doute parce qu’une meilleure base de code peut certes, un jour, donner les clés du royaume, mais l’environnement concurrentiel réel est beaucoup trop vulnérable aux pathologies et aux effets de mode.
Ce qu’on peut toutefois faire plus facilement que dans une entreprise financée par VC, c’est réserver du temps au refactoring et au traitement de la dette technique. En pratique, nous avons actuellement mis un coup de frein brutal au développement de nouvelles fonctionnalités pendant 45 jours afin de traiter des problèmes techniques majeurs. Si l’on espère être racheté l’an prochain, il est difficile de faire ce genre d’investissement, et la dette technique devient le problème de quelqu’un d’autre.
Tant que le produit continue d’être développé, de nouveaux bugs et problèmes continueront d’apparaître. Le « code parfait » n’est possible que dans un contexte fermé où aucune nouvelle fonctionnalité n’est plus ajoutée.
Je pense que le modèle de financement par VC a poussé le secteur dans cette direction. Les startups reçoivent des millions de dollars et doivent gagner de l’argent assez vite pour rembourser les investisseurs, donc elles doivent extraire de l’argent de leur application le plus rapidement possible. Tout ce qui n’est pas associé à un indicateur de ROI n’intéresse personne.
Il y avait, par défaut, l’accès ouvert, pas de mot de passe ou des mots de passe courts, un stockage non sécurisé des mots de passe, tout en clair, l’absence de nettoyage des entrées, des choses comme telnet.
C’est aussi une autre raison pour laquelle les logiciels sont devenus plus lourds. Nous avons commencé à voir les interactions et les risques, et une fois qu’on les a vus, on ne peut plus faire comme si de rien n’était. Les cas limites à gérer ne diminuent pas, ils augmentent, et il y a aussi davantage de matériel à prendre en charge.
Le processus d’écriture de code performant peut s’améliorer, mais, en même temps, la ligne de base monte plus vite que nous ne parvenons à l’atteindre. Il est d’ailleurs intéressant de constater que nous revenons peu à peu vers des approches sans mot de passe.
Une couverture élevée en tests unitaires, qui rend le refactoring douloureux, fait souvent obstacle à la livraison de fonctionnalités, et à mon avis bien plus souvent que les fanatiques du développement piloté par les tests ne veulent l’admettre. Beaucoup de « bonnes pratiques » du secteur ressemblent davantage à des dogmes irréalistes conçus par des gens qui travaillent dans des entreprises ayant déjà trouvé leur adéquation produit-marché et où l’argent rentre tout seul.
J’ai encore un HP MS200 tout-en-un tout juste utilisable. Je l’ai acheté pas cher dans un vide-garage en 2017, et avec Linux installé dessus, une fois Chrome chargé, il pouvait passer des appels vidéo plein écran avec la version web de Skype ou regarder YouTube en plein écran.
Je l’ai récemment récupéré et, avant d’en faire un ordinateur pour enfant, j’y ai installé FC38 et la dernière version de Chrome : les vidéos YouTube sont devenues un diaporama. J’ai eu beau toucher à tous les réglages, rien n’y faisait ; en passant la RAM de 2 Go à 3 Go, je suis revenu au même niveau de lecture plein écran en 720p qu’il y a six ans.
Autrement dit, pour faire la même chose, il faut 1,5 fois plus de mémoire, soit 1 Go de plus. Je sais bien qu’on dit que 16 Go est le minimum, mais même sur cette machine minable, Chrome, qui n’est quasiment qu’un navigateur web inactif, affiche une empreinte mémoire d’environ 30 Go. La majeure partie doit être constituée de fichiers mmapés, mais cela reste 30 Go.
À l’inverse, sur la plupart des appareils, l’augmentation de l’autonomie, la baisse des températures et les exigences réduites en RAM et en espace disque sont des améliorations évidentes. YouTube pourrait conserver des doublons des anciens fichiers encodés sur ses serveurs, mais dans un contexte où la majorité des utilisateurs se connectent depuis des appareils récents, ce serait du gaspillage d’espace.
La plus grande partie de l’augmentation de l’usage de la RAM par Chrome vient de l’évolution de son architecture de sandboxing. La mémoire partagée et les espaces de processus pouvant être utilisés dans des attaques d’évasion de sandbox, davantage d’isolation a été ajoutée ; le fait que Chrome lance un nouveau processus indépendant pour chaque onglet et chaque extension y contribue aussi fortement.
Aujourd’hui, les bloqueurs de publicité ont aussi un impact important. À mesure que le web s’est dégradé, les bloqueurs de publicité efficaces sont devenus plus difficiles à créer et demandent davantage de ressources. Les logiciels lents ne sont pas devenus lents uniquement pour embêter les gens ; c’est souvent le résultat du remplacement de hacks dangereux par de bonnes implémentations et de l’évolution des exigences. FLV ne suffit plus, et h264 risque lui aussi de ne pas tenir longtemps dans cinq ans, avec la diffusion de h265 et d’AV1.
Les chaînes d’outils modernes insistent sur le principe « ne réinventez pas la roue », mais si chaque dépendance a choisi une version différente de la roue, il suffit d’ajouter quelques dépendances pour embarquer six implémentations de la même fonctionnalité de bas niveau.
En revanche, ce qui était installé était un Flatpak, et on sentait l’embonpoint. Heureusement, Chrome peut encore être installé directement en natif sous forme de RPM, et utilise réellement les bibliothèques partagées de l’OS.
Ce billet ne touche même pas à la douleur principale : les bugs. Presque tous les logiciels donnent l’impression d’être aussi bogués que possible. Chaque fois qu’on utilise un logiciel par un chemin peu courant ou dans un flux anormal, ça fait peur, et ça échoue presque toujours
Il y a quelque temps, quand j’ai vendu ma voiture à Carvana, j’ai dû jongler entre Chrome et Firefox pour y arriver. Dans Chrome, l’assistant d’envoi d’images lançait une exception JS ; cette partie a miraculeusement fonctionné uniquement dans Firefox, mais le reste du site avait tellement de problèmes qu’il était évident qu’il n’avait pas été testé sur Firefox
Le pire, c’est que quand des utilisateurs non techniques rencontrent un bug, ils pensent avoir fait quelque chose de travers. Même s’il est lourd et lent, je serais désormais prêt à accepter un logiciel stable et solide
De l’autre, je vois constamment à quel point tout est bourré de bugs, et je ne sais pas si les logiciels sont réellement devenus plus bogués, ou si, en vieillissant et en connaissant mieux les coulisses, je supporte moins le développement logiciel façon grande entreprise. Ça me met en colère contre le responsable produit imaginaire qui dit « sortez la fonctionnalité X tout de suite », alors que des bugs UX évidents seraient faciles à corriger
Je comprends aussi les arguments sur le coût, le coût d’opportunité et le pragmatisme, et j’y adhère en partie, mais parfois il est difficile de ne pas avoir l’impression que nous avons simplement accepté de vivre dans un monde à moitié construit
Je n’ai pas l’impression que les choses se soient améliorées. Aujourd’hui encore, quand de jeunes enfants mettent la main sur un téléphone ou un ordinateur portable, ils peuvent assez facilement bloquer, figer ou faire planter des appareils modernes simplement en appuyant trop vite sur des boutons, ou dans un ordre inattendu. Ils ne les abîment même pas physiquement, et pourtant c’est l’état de la technologie moderne
Je comprends pourquoi ce n’est pas corrigé. Les gens se sont mis à s’attendre à devoir redémarrer de temps en temps ; dans ces cas-là, il est facile d’accuser l’enfant, et un redémarrage règle le problème. Mais vu le cycle de vie des systèmes d’exploitation, j’espérais quand même qu’on en serait plus loin maintenant
Je ne l’ai pas dit dans mon texte sur C, mais l’une des grandes raisons pour lesquelles j’utilise C, c’est qu’il est difficile d’en faire du logiciel boursouflé. On peut ajouter des fonctionnalités, mais il n’est pas facile qu’une seule fonctionnalité ajoute 100 Ko à l’exécutable
Je ne suis pas employé en ce moment, mais j’utilise une machine puissante pour le « travail ». Malgré cela, j’utilise Neovim et tmux au lieu d’un IDE, une Gentoo très modifiée plutôt qu’une distribution Linux classique, OpenRC à la place de systemd, et un gestionnaire de fenêtres en tuiles appelé Qtile au lieu d’un environnement de bureau complet
Je garde ma machine aussi peu encombrée que possible, au point qu’il n’y a que 40 processus juste après le démarrage et la connexion. En ce moment, je fais vraiment de l’ingénierie logicielle. J’essaie d’atténuer efficacement les problèmes de C tout en gardant les logiciels petits et rapides, et j’espère un jour pouvoir bâtir une activité par-dessus
On verra s’il existe encore un marché pour des logiciels légers et réactifs
https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-i...
https://gavinhoward.com/2020/12/my-development-environment-a...
https://gavinhoward.com/2023/06/an-apology-to-the-gentoo-aut...
https://gavinhoward.com/2023/09/lessons-learned-as-a-user-3-...
Des programmes des années 1980 comme WordPerfect, Lotus 123, MS-DOS 1.0 ou SubLogic Flight Simulator avant son rachat par Microsoft étaient écrits en assembleur. À l’époque, les observateurs du secteur estimaient que Microsoft itérait plus vite sur de nouvelles fonctionnalités et portait plus rapidement ses logiciels vers d’autres architectures que WordPerfect et Lotus 123 parce que MS Word et MS Excel étaient écrits dans le C « boursouflé ». Leurs concurrents étaient restés trop longtemps sur l’assembleur
Je vois le même compromis dans les logiciels personnels. Utiliser du C#/Python, plus haut niveau et plus « boursouflé », au lieu de C/C++ plus léger, permet de terminer certaines tâches beaucoup plus vite. Je suis plus à l’aise en C++ et je préfère les petits exécutables, mais si C# me permet de terminer plus vite ce que je veux faire, cet avantage ne compte plus. Moi aussi, je fais partie du problème des logiciels boursouflés
« Je vais construire le pont le plus solide et le plus léger du monde » est une merveille ; « je vais construire un pont assez léger et assez solide pour un coût que le client peut se permettre » relève de l’ingénierie
J’ai lu un peu plus de la moitié avant d’arrêter, mais l’argument central semblait être que les logiciels doivent être rapides, et je ne me souviens d’aucune justification de cette philosophie, sinon l’insinuation que c’est « simplement vrai ». L’auteur reconnaît l’objection selon laquelle, dans certains cas, les gains d’efficacité ne compensent jamais le coût en temps passé à rechercher cette efficacité, mais il passe dessus sans vraiment se confronter à l’argument
Une autre caractéristique centrale du texte était de sélectionner les données qui l’arrangent et de simplifier à l’excès le domaine. Il lance plusieurs fois l’appel émotionnel « mais qu’est-ce que le logiciel fait donc avec tout ce temps et tout cet espace ? », sans essayer d’y répondre sérieusement, puis utilise l’absence de réponse comme si c’était la preuve d’une mauvaise réponse. Il compare aussi plusieurs logiciels qui ne sont pas fonctionnellement équivalents comme si seule leur performance différait
Il y a beaucoup à dire sur les coûts sociaux, environnementaux et business de l’inefficacité, ainsi que sur des logiciels plus efficaces, mais il vaut aussi la peine de discuter du fait que le logiciel moderne permet à des gens qui, autrement, n’auraient rien pu créer, de fabriquer quelque chose de « mauvais » dont ils ont besoin. De même qu’un ingénieur structure choisit quelque chose de « suffisamment solide », les développeurs modernes visent souvent quelque chose de « suffisamment rapide »
Il y a beaucoup de matière à débat, mais ce texte reste dans la colère émotionnelle et ne traite pas vraiment de raison ni d’argumentation. Certaines affirmations contiennent une part de vérité, mais le texte lui-même montre clairement, à mon avis, qu’il n’a pas l’intention de débattre
Le réseau a aussi plus de chances d’être de la 5G à plusieurs centaines de Mbps ou de la fibre, plutôt que de la 2G à quelques kbps. Au bout du compte, les actes parlent plus fort que les mots, et si la société entière suit l’axiome du « logiciel plus rapide », on peut l’accepter comme vrai
C’est en particulier un axiome qui vient du même endroit que l’idée selon laquelle « le temps des développeurs a plus de valeur » ; la seule différence est de savoir de qui on économise le temps
Si les développeurs ne testent pas aussi sur des appareils bas de gamme, ils ne peuvent pas du tout voir ce problème. Le vrai problème n’est pas tant technique que l’attitude de certains développeurs qui deviennent défensifs et commencent par débattre lorsqu’ils sont confrontés à cette vérité inconfortable : leur code est trop lent. Il faut s’asseoir avec le chef de produit, réserver du temps pour le profiling et l’optimisation, et voir comment atténuer les problèmes de performance sans tout réécrire depuis le début
BASIC et SQL avaient eux aussi depuis longtemps pour objectif de permettre aux gens de créer quelque chose de « mauvais », tout comme Fortran et plusieurs langages et technologies aujourd’hui disparus
Python ou Java sont, même en étant généreux, conservateurs, et si l’on pense aux progrès des langages de programmation dans les années 70, il faudrait en fait les qualifier d’anachroniques. J ou Prolog sont conceptuellement bien plus avancés que Rust ou Go, tout en ayant été créés plus tôt. Quant au C accumulé de C89 à C23, est-ce un langage moderne, est-ce seulement C23 qui est moderne, et y a-t-il vraiment une grande différence entre C89 et C23 ? Tout cela reste flou
Si ce n’est pas la date de création ni un arbre d’évolution imaginaire, je me demande s’il existe une autre manière de définir la modernité
C’est une vieille plainte. Beaucoup de conforts que nous tenons pour acquis ont un coût, et ce coût s’accumule énormément. Un écran 4K a 17 fois plus de pixels qu’un 800x600 et utilise des couleurs 32 bits, donc la taille brute des graphismes pour les écrans modernes est environ 68 fois plus grande
Autrefois, une image statique suffisait, mais aujourd’hui les animations de haute qualité à fréquence élevée sont la norme. Arial Unicode est une police de 15 Mo, qui n’aurait même pas tenu dans la mémoire de la plupart des ordinateurs faisant tourner Windows 95
La correction orthographique est devenue évidente partout, et toutes ces choses s’additionnent. Malgré tout, elles rendent l’ordinateur bien plus agréable à utiliser. Les modes vidéo 16 couleurs ne me manquent pas, ni l’époque où l’on ne pouvait pas utiliser simultanément deux langues autres que l’anglais sans contournements extrêmement pénibles
En revanche, je ne veux pas d’animations dont la seule raison d’être est de rendre l’attente moins ennuyeuse. Unicode mérite aussi qu’on en paie le coût
Mais il devrait toujours être possible d’afficher un glyphe à l’écran en un nombre de millisecondes à un seul chiffre, comme en 1981. Il y a plus de pixels et plus de glyphes, mais c’est possible ; ce n’est tout simplement pas une priorité
C’est un peu comme payer 100 000 dollars pour une BMW sportive, puis entendre l’ingénieur dire qu’elle met 30 secondes pour passer de 0 à 60 mph, et que l’utilisateur, n’étant pas expert en performance, devrait simplement l’accepter
J’ai observé une dynamique similaire dans mon organisation actuelle. Au début, quand l’équipe était petite, les détails comptaient. Il ne fallait pas que ce soit lent, les animations devaient être fluides, la vitesse de défilement et les temps de chargement étaient importants, et on essayait de créer le produit le plus efficace possible pour améliorer l’efficacité des utilisateurs
À mesure que l’équipe a grandi, la valeur s’est déplacée vers l’amélioration de l’efficacité des développeurs. Davantage d’abstractions, de couches et de frameworks sont arrivés, et on a accepté le compromis consistant à économiser une journée de développeur au prix de millions de secondes cumulées pour l’ensemble des utilisateurs
La différence tient à la visibilité. La direction peut voir les coûts côté développement, mais ne voit pas les bénéfices d’un temps d’exécution un peu plus rapide, d’un meilleur caching ou d’un défilement plus fluide. Parce que ce n’est pas mesuré. Quand une organisation en arrive à ne se soucier que des chiffres mesurables, cette évolution paraît naturelle
Évidemment, cela vaut jusqu’au moment où l’IA atteindra le point où elle pourra corriger ce que nous avons mal écrit, ou ce que l’IA a mal écrit, ainsi que l’IA elle-même, très inefficace comme le prédit l’article d’origine
Les voitures n’ont été optimisées qu’après un choc pétrolier externe, et même alors de façon très inégale. En réalité, les produits inefficaces sont souvent plus rentables, car les clients doivent les remplacer plus souvent. Un mauvais câble iPhone qui se fissure au bout d’un an permet à Apple de facturer des remplacements encore et encore. L’électroménager tombe plus souvent en panne, mais coûte moins cher à fabriquer, ce qui augmente la marge par unité. Ce qui compte, ce n’est pas l’efficacité d’usage après la vente, mais l’efficacité de production
Dans le logiciel, le capitalisme fonctionne en déversant de nouvelles automatisations le plus vite possible, puis en laissant les consommateurs assumer le gaspillage d’énergie et de temps. La chaîne de production est de plus en plus standardisée et optimisée, au point qu’un développeur React ou un administrateur Kubernetes peut être remplacé comme un manutentionnaire, avec la pression salariale que cela implique. Une partie de l’automatisation relève presque de l’autojustification, comme le fait de rendre le jargon comptable obscur pour justifier un métier ; le reste relève du profit
Tout a un coût. Quand le coût de calcul ou la dégradation de l’expérience utilisateur devient suffisamment important, on optimise l’efficacité. Les modèles de ML en sont un exemple. Dans les autres cas, on n’optimise pas, parce que les utilisateurs finaux ne le veulent pas au point d’accepter moins de fonctionnalités
Les voitures consommaient aussi beaucoup autrefois, mais cela a changé quand le coût du carburant et les préoccupations environnementales ont amené les clients à vouloir autre chose. Beaucoup d’ingénieurs oublient qu’ils sont payés pour construire un produit pour les clients
Par ailleurs, l’auteur de l’article d’origine ne semble jamais avoir attendu qu’une vieille machine Windows ou Linux démarre complètement. Les versions modernes démarrent beaucoup plus vite parce que les clients l’ont voulu. Les téléphones restent allumés 24 h/24, donc les clients se moquent qu’un démarrage prenne longtemps une fois tous les quelques mois
Mon BIOS met environ 20 secondes à passer le POST, et on me dit que c’est normal. Ensuite, le démarrage de l’OS prend environ 10 secondes
On peut aussi dire que les médecins ou les ingénieurs sont payés pour développer de nouveaux médicaments ou de nouvelles sources d’énergie, mais ces domaines sont sensibles et importants, d’où l’existence de plusieurs niveaux de contrôle gouvernemental. Le logiciel n’a pas encore ce niveau de contrôle
Elles ont le pouvoir de façonner l’environnement lui-même, et donc de réorienter fortement le résultat de la « demande client »
Cet article date de 2018, et il y a déjà eu plusieurs discussions auparavant
https://news.ycombinator.com/item?id=18012334 (sept. 2018)
https://news.ycombinator.com/item?id=21929709 (janv. 2020)
https://news.ycombinator.com/item?id=31798580 (juin 2022)
Je suis profondément d’accord. En tant que développeurs, il est important de se rappeler que nous avons le choix. Nous ne pouvons pas tout choisir, mais nous pouvons choisir des alternatives moins mauvaises
Rien ne nous oblige à utiliser Node. On peut écrire d’excellents logiciels rétrocompatibles dans les écosystèmes .NET ou JVM, et s’attendre à ce qu’ils fonctionnent encore dans dix ans sans modification
Rien ne nous oblige non plus à créer des pages web en single-page app. Le vieux HTML à l’ancienne, qui recharge entièrement la page à chaque clic, fonctionne très bien, et à ce stade il peut même offrir une latence plus faible
Rien ne nous oblige à construire des applications desktop avec Chromium. Démarrer avec un framework d’interface demande un peu plus de travail, mais la qualité en vaut la peine. On n’a pas toujours le pouvoir de décision, mais quand on l’a, il faut s’écarter des mauvais choix