Licence CC BY-SA

[Billet Signet] Le désenchantement du logiciel

Publié :
Auteur :
Catégorie :
Temps de lecture estimé : 1 minute

Je suis tombé il y a peu sur un article fort intéressant, écrit par un certain Romain Fallet, sur le « désenchantement logiciel », que j’ai cru bon de vous partager.

https://blog.romainfallet.fr/desenchantement-logiciel/

L’auteur y explique sa vision de l’évolution du logiciel et de l’informatique, et cherche à comprendre pourquoi les programmes sont de plus en plus lents (ou au moins, toujours aussi lents qu’avant), alors que les ordinateurs qui les font tourner sont de plus en plus puissants.

Je programme depuis 15 ans maintenant. Récemment, le manque d’attention de l’industrie du logiciel en matière d’efficacité, de simplicité et d’excellence a commencé réellement à me peser, au point d’être déprimé par ma propre carrière et l’informatique en général.

Les voitures modernes utilisent 98 % — pour ne pas dire 100 % — de ce que permettent les limites physiques actuelles induites par la conception de leurs moteurs. Les constructions modernes utilisent juste ce qu’il faut de matières premières pour remplir leur fonction tout en étant suffisamment résistantes pour garantir la sécurité de leur ensemble sous certaines conditions. Tous les avions convergent vers le meilleur rapport poids/taille/capacité de chargement et fonctionnent fondamentalement sur le même principe.

Il n’y a qu’en logiciel qu’on accepte qu’un programme tourne à 1 % voire même 0,01 % de ses performances optimales. Tout le monde semble être d’accord avec ça.

[…]

Regardez autour de vous : nos ordinateurs portables sont mille fois plus puissants que ceux qui ont emmené l’Homme sur la Lune. Et pourtant, les pages web ont du mal à maintenir une vitesse de défilement constante de 60 fps sur la dernière version du MacBook Pro.



12 commentaires

Ce point de vue me parait sacrément biaisé.

Les voitures modernes utilisent 98 % — pour ne pas dire 100 % — de ce que permettent les limites physiques actuelles induites par la conception de leurs moteurs.

Déjà on roule pas tous en Mc Laren (ce qui serait de toute façon inutile puisque les limitations de vitesse sur les routes sont bien inférieures à ce qu’on est capable de produire), et le moteur thermique est sacrément mauvais point de vue énergétique (je ne parle pas du point de vue environnemental, c’est purement thermodynamique, il y a des pertes énormes en bruit et chaleur).

Les constructions modernes utilisent juste ce qu’il faut de matières premières pour remplir leur fonction tout en étant suffisamment résistantes pour garantir la sécurité de leur ensemble sous certaines conditions.

Ça, ça doit être à peu près vrai, si on considère que les 15–20% de marge pour des raisons de sécurité nous amènent à "juste ce qu’il faut".

Tous les avions convergent vers le meilleur rapport poids/taille/capacité de chargement et fonctionnent fondamentalement sur le même principe.

Je sais pas comment il définit "meilleur", mais les compagnies qui grattent comme des dingues sur l’espace des jambes font pas le choix prix/confort que j’aurais choisi. :-°

Il n’y a qu’en logiciel qu’on accepte qu’un programme tourne à 1 % voire même 0,01 % de ses performances optimales. Tout le monde semble être d’accord avec ça.

Je sais pas dans quel domaine logiciel il travaille, mais ça me semble un peu excessif comme chiffre. Au boulot, on essaye d’obtenir les meilleures perfs possibles sur nos logiciels de calcul (en restant sur des temps de développement raisonnables pour les humains que nous sommes). Le secteur du jeu vidéo fait des progrès gigantesques en terme d’optimisations (c’est plus difficile à voir parce qu’en même temps, ce qu’on demande des jeux augmente énormément aussi).

En fait, l’observation que les logiciels de "tous les jours" n’apparaissent pas plus rapides qu’avant vient plutôt du fait qu’on leur demande des choses de plus en plus complexes qui viennent compenser les progrès matériel. C’est pas que les gens codent comme des sagouins. Si sa page web est un monstre de complexité, faut déjà être content qu’elle charge aussi vite, voire plus, qu’une page html d’il y a 20 ans.

I don’t mind that you think slowly, but I do mind that you are publishing faster. — W. Pauli

+1 -0

Le plus gros problème, c’est que la très vaste majorité des logiciels sont écrits pour faire du profit avec des logiques court terme. Si rendre un logiciel deux fois plus rapide n’augmente pas significativement les ventes ou les revenu publicitaires mais coûte de la main d’œuvre, ça ne sera pas fait.

Une des multiples raisons pour lesquels j’utilise vim comme éditeur, c’est qu’il ne bronche pas quand j’ouvre un fichier texte de plusieurs Mo. Toutes mes expériences avec des IDE se résument à attendre plusieurs dizaines de secondes dès que je veux manipuler un fichier de plus d’un millier de lignes.

+0 -0

En fait, l’observation que les logiciels de "tous les jours" n’apparaissent pas plus rapides qu’avant vient plutôt du fait qu’on leur demande des choses de plus en plus complexes qui viennent compenser les progrès matériel. C’est pas que les gens codent comme des sagouins. Si sa page web est un monstre de complexité, faut déjà être content qu’elle charge aussi vite, voire plus, qu’une page html d’il y a 20 ans.

Mouais, je ne suis pas convaincu. Y’a quand même des phénomènes pathologiques qui ont été clairement observés et identifiés pendant la dernière décennie.

Si l’article parle de performances, c’est parce que c’est là que le problème se fait sentir, mais le problème, ce n’est pas tellement que les devs ne prennent plus le temps d’optimiser leurs softs : c’est que la grosse majorité de l’industrie n’applique les concepts Agile que quand ça l’arrange.

Quand la philosophie Agile dit que la priorité d’une équipe, c’est de répondre le plus tôt possible et (itérativement) de mieux en mieux aux besoins des clients, sans rien préciser d’autre, ça a tendance à l’enfermer dans une vision court-termiste, dans laquelle on n’envisage même plus aboutir à des designs qui sont à la fois simples et durables. On fait simple, on fait de la valeur immédiate, mais quand le besoin des utilisateurs change pour une raison ou une autre (ce qui arrive tout le temps), rares sont les équipes auxquelles ont donne les moyens de refactoriser et consolider leur design. Il y a bien quelques méthodos qui laissent une place à la refacto (XP, notamment), mais elles ne sont suivies de façon marginale, par rapport à Scrum que quasiment tout le monde suit (et souvent mal).

C’est bête, mais on oublie que la première initiale de "KISS" est pour Keep, et la règle qui se retrouve le plus souvent appliquée, c’est "Make It Simple, Stupid". À cause de ça, la tendance naturelle des softs, c’est de finir surchargés de couches diverses et de fonctions qui font à peu près le job sans avoir été pensées pour à l’origine.

Alors bien sûr, c’est pas trop le cas dans certaines niches où les temps de calcul sont primordiaux, mais globalement, il n’y a qu’à voir la quantité de merde qui intervient dans la génération d’une page web banale de nos jours (et l’odeur de "transpilation" qui s’en dégage) pour se dire que l’industrie est malade. Je ne suis vraiment pas convaincu que les besoins des utilisateurs soient tellement plus complexes qu’il y a 10 ans que cela justifie que ce soit plus lent aujourd’hui : quand je clique sur une notification de SMS sur mon smartphone, c’est pour afficher le message, et je n’ai aucune raison d’accepter que ça puisse prendre plus d’une seconde aujourd’hui alors que c’était instantané sur un téléphone 8 fois moins puissant il y a quelques années, et que le besoin n’a strictement pas bougé pendant tout ce temps.

Édité par nohar

I was a llama before it was cool

+1 -0

dans laquelle on n’envisage même plus aboutir à des designs qui sont à la fois simples et durables.

Je constate même que l’agile est souvent utilisé pour justifier le fait de ne faire aucune conception tout court. Ou qu’on accepte n’importe quel changement d’avis du client sur le projet initial sans allouer le temps nécessaire à réétudier l’impact sur la conception d’origine choisie.

Amateur de Logiciel Libre et de la distribution GNU/Linux Fedora. #JeSuisArius

+4 -0

dans laquelle on n’envisage même plus aboutir à des designs qui sont à la fois simples et durables.

Je constate même que l’agile est souvent utilisé pour justifier le fait de ne faire aucune conception tout court. Ou qu’on accepte n’importe quel changement d’avis du client sur le projet initial sans allouer le temps nécessaire à réétudier l’impact sur la conception d’origine choisie.

Renault

Ouais, c’est le Agile fantasmé par les chefs de projet qui n’ont retenu que des approximations du style "pas de spec", "le client d’abord", etc.

Ça me scie de constater que ça puisse exister encore aujourd’hui.

J’ai un petit peu le même problème avec ma hiérarchie : globalement dans ma boîte les gens ont compris la philosophie et l’appliquent à peu près correctement, mais chaque fois que je discute avec eux, je m’aperçois qu’ils n’ont qu’une vision parcellaire de ce que cela implique, en particulier en ce qui concerne la gestion de la dette technique. Et évidemment, puisque je suis tech lead, il est plus facile pour eux de considérer que c’est moi qui centre mon point de vue sur la technique, et donc qui grossis le trait. :)

Le problème de ce genre de situation, c’est que ça demande énormément de patience pour les détromper, et qu’il y a bien souvent des centaines de choses plus urgentes à faire, du coup il est bien moins coûteux d’attendre que quelque chose pète de façon critique pour qu’ils le constatent par eux même (tout en se retenant de sortir "j’vous l’avais bien dit!").

Édité par nohar

I was a llama before it was cool

+0 -0

Le problème de ce genre de situation, c’est que ça demande énormément de patience pour les détromper, et qu’il y a bien souvent des centaines de choses plus urgentes à faire, du coup il est bien moins coûteux d’attendre que quelque chose pète de façon critique pour qu’ils le constatent par eux même (tout en se retenant de sortir "j’vous l’avais bien dit!").

J’ai eu le cas d’un client où le management à ce propos était totalement aberrant.

J’ai débuté un projet où j’étais seul au niveau logiciel, les specs étaient minimales. Les 4 premiers mois on est allé de POC en POC. Peu de vision de produit, pas de specs… Mais comme on réinventait les fonctionnalités du logiciel tous les 4 matins, autant dire que le refactoring était courant. Le client trouvait qu’on perdait trop de temps dans le développement, ce qui est vrai dans le fond. Et là se produit l’échange la plus surréaliste de ma carrière :

-On irait plus vite avec des specs définies, on pourrait avoir une bonne architecture une bonne fois pour toute.

-On a pas besoins de specs, on a besoin d’un produit qui fonctionne.

À partir de là, comment faire de la qualité et un temps de travail raisonnable si on part du principe que tout peut et doit être développé au fil de l’eau ? C’est comme construire une maison sans plans et avec un planning absurde (on va carreler avant de poser l’électricité et la plomberie). Ce n’est pas possible. Hélas c’est vrai que dans l’univers du logiciel ces situations sont trop courante, probablement car on peut faire des MaJ facilement après coup et que c’est habituel.

Amateur de Logiciel Libre et de la distribution GNU/Linux Fedora. #JeSuisArius

+0 -0

À partir de là, comment faire de la qualité et un temps de travail raisonnable si on part du principe que tout peut et doit être développé au fil de l’eau ?

En fait, je suis absolument convaincu que c’est possible, mais pas n’importe comment et pas avec n’importe quel client. Pour débuter un tout nouveau dev dans ces conditions, il est indispensable de passer du temps avec le client, ou plutôt avec l'utilisateur final, sans passer par l’intermédiaire du commercial qui va vendre un sapin de Noël à clochettes avec des boules d’Halloween qui chantent La cucaracha, et tout ça avec du Big Data dans le cloud, à un chef qui ignore trop souvent la réalité du métier de ses subordonnés : l’ingénierie logicielle fonctionne hyper mal quand on la fait passer par des intermédiaires, et encore plus quand on n’essaye pas de répondre en priorité à la question "Ce logiciel, tu veux qu’il serve à quoi ? Qu’il t’aide à faire quoi ?".

Et pourtant, c’est fou le nombre de projets dans lesquels personne n’est foutu de répondre simplement à cette question, ou bien où chaque acteur ou presque y apporte une réponse distincte et contradictoire.

Édité par nohar

I was a llama before it was cool

+0 -0

Bah avec ce que tu me décris, j’ai l’impression que très rapidement tu aboutis à des specs assez aboutis même si c’est peut être moins formel que cela. Donc on s’éloigne de ce que je dis à savoir de faire du développement sans plan, où chaque fonctionnalité est découverte au fur et à mesure et où des pans importants du logiciel sont remis en question un peu n’importe quand.

Car si tu discutes avec le client sur l’objectif que doit remplir le logiciel et éventuellement comment y parvenir (des idées d’interface et de fonctionnalités par exemple). Tu as des specs assez solides pour commencer le travail et en théorie le résultat de ces réunions et autres discussions ne devront pas être trop remises en question ou trop souvent. Sinon c’est que le but même du logiciel a évolué et dans ce cas tu peux faire ce que tu veux, tu ne peux pas vraiment l’anticiper convenablement.

Amateur de Logiciel Libre et de la distribution GNU/Linux Fedora. #JeSuisArius

+0 -0

Tu as des specs assez solides pour commencer le travail et en théorie le résultat de ces réunions et autres discussions ne devront pas être trop remises en question ou trop souvent.

Oui, disons que les prémisses de base ne changent pas ou peu et pour elles il faut se mettre au diapason, par contre pour chaque fonctionnalité une fois la base acquise, il vaut mieux ne pas faire trop confiance à une spec qu’on implémente de A à Z mais partir sur simple et itérer avec l’utilisateur, parce que c’est souvent là qu’on se rend compte que ce dont il a besoin diffère de ce qu’il a demandé au début.

En fait je distingue spec et requirements : ce sont les seconds qui sont indispensables, et ils sont impossibles à anticiper tant que l’utilisateur n’a pas vu un logiciel qui tourne pour dire "Ah en fait ce serait mieux si on déplaçait ce truc ici, j’aurais besoin qu’il me donne telle ou telle info en plus, en fait tel truc ne me sert à rien en réalité, etc.".

Édité par nohar

I was a llama before it was cool

+0 -0

On oublie un peu qu’un développeur, c’est un ingénieur. On demanderait pas à un architecte de construire un pont morceau par morceau, sans conception initiale, en trois jours alors qu’il faut trois mois, et de changer trois fois en cours de route les matériaux.

Édité par Society

+2 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte