[~Signet] Software disenchantment

Je suis d’accord avec l’article, notamment parce que je suis sensible à la latence. Je déteste les animations inutiles, et je les désactive dès que possible. J’ai aussi un projet récent dans lequel j’ai pu gagner facilement un facteur 2000 entre la version actuelle et la preuve de concept.

Pour progresser, je pense que l’informatique devrait prendre conscience qu’un code source n’est pas forcément fait pour être réutilisé. On peut faire une analogie : si un programme informatique était une pièce mécanique, alors le code serait un plan, et le compilateur serait une ligne de fabrication. Maintenant, est-ce qu’on copie-colle les plans pour faire un objet neuf ? Des morceaux oui, c’est certain, mais la plupart du temps, on est pas entrain de créer des chimères.

Si on récupère tout, on a de la dette technique. Dans l’informatique, elle concerne beaucoup le code, dans mon domaine, elle concerne plutôt les spécifications et les plans, puisque c’est ce qui reste d’un projet à l’autre. On part sur un nouveau client, on dit "spec identique aux clients précédents, sauf spécificités". On se retrouve plus tard avec toutes les erreurs dans la spec qu’on a pas voulu changer, plus toutes les rustines pour coller au besoin du client actuel, plus tous les défauts habilement cachés à l’aide de paramètres bien choisis dans le logiciel. À la fin, on fabrique un objet, mais on en a pas pu profiter du nouveau projet pour nettoyer un peu les recoins de la spec, ce qui a des effets sur la facilité de développement, la validation du produit, et la saisie d’opportunités (de baisse des coûts souvent).

En fin de compte, c’est une question de coût cachés : se traîner la dette technique, c’est transformer une modification mineure en cauchemar, mais comme on ne voit pas ce coût, c’est « gratuit ». On retrouve cela sur plein de petites décisions managériales. Exemple facile : faut-il acheter une licence à 1000 € par an pour cet ingénieur ? Réponse du trésorier : non trop cher. Résultat : l’ingénieur refait un outil en moins bien, moins bien validé, sans opportunités (l’outil remplit potentiellement d’autres besoins) et mets 10 jours à faire ça : félicitations, l’entreprise vient de perdre de l’argent en plus de perdre deux semaines de travail utile par ailleurs. Dans la même veine, je pourrais commenter le passage de la suite Office à Google Suite dans ma boîte : avec tout le temps que j’ai perdu, j’aurais pu me payer Office 365 pendant 5 ans déjà (et ils sont quand même obligés de me payer Office, on choisit pas ses clients).

Pour progresser, je pense que l’informatique devrait prendre conscience qu’un code source n’est pas forcément fait pour être réutilisé. On peut faire une analogie : si un programme informatique était une pièce mécanique, alors le code serait un plan, et le compilateur serait une ligne de fabrication. Maintenant, est-ce qu’on copie-colle les plans pour faire un objet neuf ? Des morceaux oui, c’est certain, mais la plupart du temps, on est pas entrain de créer des chimères.

AMEN ! Je ne compte plus l’énergie que j’ai été obligé de sacrifier ces dernières années sur l’autel de la Sacro-Sainte Réutilisation du Code Qui Fait Quasiment le Job.

Enfin dans mon cas, même si ça prend beaucoup de temps et de patience, je trouve que la situation a tendance à s’améliorer. Il faut dire aussi que je ne suis pas connu pour mâcher mes mots quand quelque chose me gonfle au boulot. Autant je ne bloque pas les décisions (ce serait vraiment pas pro), autant j’ai pris l’habitude de bien faire sentir mon exaspération et à quel point la situation est absurde quand on doit concevoir un satellite et l’envoyer en orbite pour le lendemain avec deux sparadraps et trois bouts de bois.

Il y a des gens qui travaillent sur des systèmes mieux conçus et plus fiables (mais pas forcément plus rapides; on ne peut pas tout avoir à la fois).

Dans ma communauté (autour du langage fonctionnel OCaml), le projet Mirage OS permet de déployer des toutes petites machines virtuelles (quelques Mio) pour fournir un service donné, qui sont efficaces, écrits dans un langage de haut niveau qui rend une pelletée de bugs moins probables, et qui font des efforts en continu pour trouver les bons schémas de conception pour avoir du code robuste.

Le projet Qubes OS propose un système d’exploitation qui met en avant une compartementalisation forte (en gros, au lieu de répartir ses tâches dans plusieurs bureaux virtuels qui tournent dans le même système, l’utilisateur a accès à des systèmes d’exploitations complètement séparés, avec des protocoles spécifiques d’échange d’information), et donc nettement plus sécurisés.

Google a un projet Fuchsia pour refaire un noyau de système plus moderne et plus sécurisé. On connaît depuis longtemps la famille de micronoyaux L4 qui permet une bonne compartementalisation des services systèmes avec un surcoût très faible. Le projet Capsicum a proposé une approche pour permettre une meilleure compartementalisation des programmes tournant sur tout système de la famille UNIX… mais les gens du noyau Linux n’ont jamais été intéressés, seul FreeBSD a vraiment intégré ce travail. OpenBSD a développé un système plus simple et moins flexible que Capsicum, pledge, et fait des efforts pour l’utiliser dans ses utilitaires… mais les utilisateurs d’autres systèmes regardent ailleurs et ne font pas d’effort pour adapter leur logiciel à ces meilleures méthodes de conception.

La communauté universitaire et/ou de recherche travaille depuis des années à des outils de vérification de programme, complète (on vérifie qu’un programme respecte une certaine spécification) ou partielle (on vérifie que tout une catégorie d’erreurs ne peuvent se produire). Elle a produit de très beaux résultats (un compilateur C vérifié, une version vérifiée de L4, de Minix, des hyperviseurs vérifiés, un serveur XML-RPC entièrement prouvé…), mais encore une fois les industriels et la communauté du logiciel libre regardent ailleurs, ne sont pas prêt à faire l’effort d’essayer ces outils et d’essuyer les plâtres nécessaires pour un passage à l’échelle. (Sauf quelque cas exceptionnels: Mozilla a intégré une implémentation vérifiée de primitives cryptographiques développées par Microsoft Research et l’INRIA.)

Quelques points positifs au hasard: RISC-V, un jeu d’instructions processeur bien conçue et entièrement ouverte; on aura peut-être des machines efficaces avec une conception ouverte, un jour. WebAssembly, un langage bas-niveau portable et potable, à la base destiné au web mais qui pourrait à terme être une bonne base commune pour compiler des langages de plus haut niveau, un peu comme LLVM mais en moins bloaté. Rust, un langage poussé par Mozilla qui essaie de faire avancer les choses, au lieu de viser le plus petit dénominateur commun des programmeurs pour gagner la course à la popularité. En comparaison, Google continue à coder en Java et C++ (et a inventé son propre langage pourri, Go, parce que c’était moins compliqué que d’améliorer les outils d’un langage existant pour le rendre agréable à utiliser pour leurs usages), et Facebook a des millions de ligne de PHP à gérer.

L’auteur du billet "Software disanchentment" reste dans un milieu "mainstream" fermé d’esprit et râle sur les technologies Worse-Is-Better qu’il produit. Il écrit des absurdités énorme comme "We haven’t seen new OS kernels in what, 25 years?", parce qu’il n’a pas fait l’effort de s’intéresser aux choses intéressantes qui sont développées. C’est assez paradoxal de râler contre la médiocrité dans la course à la popularité / les parts de marché, et en même temps de ne pas faire soi-même l’effort de se renseigner sur les projets qui font des efforts pour avancer l’état de l’art, à part en citant trois trucs qu’il a vu sur Hacker News. Comme quoi les bandeaux sur les yeux ne sont pas seulement chez les autres.

SpaceFox, tu proposes de mettre en avant une fierté du travail bien fait chez les développeurs, et l’idée que c’est notre responsabilité de faire pression pour pouvoir bien travailler (et pas de se faire dicter comment faire par le client). Pourquoi pas, c’est le mouvement de Software Craftmanship par exemple.

Mais peut-être qu’une autre chose à faire serait de réfléchir à bosser sur des projets qui font avancer les choses, au lieu de bosser "mieux" sur une application mobile qui ne rend pas le monde meilleur pour grand monde. Pour tous les projets que j’ai cités ci-dessus, il est possible de trouver un job à temps plein pour y contribuer de façon productive, tout en répondant à des besoins de clients. (Ça peut demander un peu de recherche, et d’avoir contribué au(x) projet(s) avant.) Pourquoi ne pas commencer par trouver un projet qui a ces qualités, s’y impliquer un peu, et essayer d’en faire son métier ?

C’est très honorable de "programmer correctement", mais c’est encore mieux si le programme qu’on écrit est là pour rendre le monde meilleur.

Mais peut-être qu’une autre chose à faire serait de réfléchir à bosser sur des projets qui font avancer les choses, au lieu de bosser "mieux" sur une application mobile qui ne rend pas le monde meilleur pour grand monde. Pour tous les projets que j’ai cités ci-dessus, il est possible de trouver un job à temps plein pour y contribuer de façon productive, tout en répondant à des besoins de clients. (Ça peut demander un peu de recherche, et d’avoir contribué au(x) projet(s) avant.) Pourquoi ne pas commencer par trouver un projet qui a ces qualités, s’y impliquer un peu, et essayer d’en faire son métier ?

C’est très honorable de "programmer correctement", mais c’est encore mieux si le programme qu’on écrit est là pour rendre le monde meilleur.

À te lire j’ai l’impression que tu résumes les jobs en développement et leur intérêt aux seules qualités (techniques, conceptuelles, éthiques) intrinsèques du produit. De mon expérience, ça n’est pas du tout le seul critère à entrer en ligne de compte.

Typiquement, on peut très bien travailler pour arriver à produire le meilleur soft du monde, avec des processus et un état d’esprit moderne (du genre qu’on ne voit que sur le net et jamais en vrai), et se faire pourrir la vie par des développeurs historiques que l’ego a transformé en divas, ou même arriver sur un bon projet dans une équipe à l’état d’esprit de laquelle on n’adhère pas du tout, et inversement.

Ce que je veux dire par là, c’est qu’à cette vision idéaliste, il faut aussi confronter une réalité difficile : même quand on a un profil que les recruteurs s’arrachent, on ne change pas de boulot comme de chemise. C’est tout à fait louable de vouloir rendre le monde meilleur, mais on ne peut pas demander à quelqu’un d’y sacrifier sa qualité de vie au travail. Et je parle de vraie qualité de vie : celle qui fait que c’est un plaisir d’aller bosser tous les matins, donc pas d’une table de ping-pong ni d’un babyfoot dans les locaux.

Pour résumer, je dirais que rendre le monde meilleur, contrairement à ce passage que je cite, je crois vraiment que ça commence par le changer autour de soi. Si on a la possibilité d’améliorer les choses à son échelle, c’est là qu’il faut commencer, en montrant l’exemple. Ça me semble plus sain que de chercher un ticket pour l’arche de Noé.

@gasche Tu sembles dans ta seconde partie oublier l’essentiel : le billet et mes réflexions portent sur l’industrie informatique dans son ensemble, ce qui implique en particulier ceci :

• Le point le plus important : le pilotage des projets à l’économie d’argent et à la vue courte est le standard, et pratiquement tout le reste dépend de cela.
• Il en découle que les principes de « bonne conception », de sécurité ou de stabilité sont quasi-systématiquement mis à la trappe, c’est la raison d’être du billet.
• Ce qui implique une frilosité extrême au risque technologique (contrairement à ce qu’essaient de faire croire toutes les startup). Si une technologie existe et permet de faire ce qu’on veut rapidement et de manière rentable, elle est sélectionnée, point.
• Conséquence : les projets intéressants que tu montres en première partie ne sont pas sélectionnés faute de rentabilité à court terme démontrée.
• Autre conséquence : du point de vue de l’industrie, le fait de de n’avoir aucun nouveau noyau d’OS depuis 25 ans est un fait, pas une absurdité. Les choses intéressantes ne sont pas encore du domaine de l’industrie.
• Enfin, le problème est général et doit trouver une solution générale ; trouver un projet et en faire son métier est une solution égoïste qui n’est pas très satisfaisante dès qu’on regarde au-delà de sa vie personnelle.

Même si le Software Craftmanship et les améliorations autour de soi sont utiles, la vraie question qui découle de tout ça est : comment provoquer une prise de conscience généralisée des problèmes du développement actuel et donc comment modifier tout ça au niveau de l’industrie ?

Je n’ai pas spécialement de réponse. Ça impliquerait à la fois une prise de conscience à grande échelle des développeurs (pour refuser de se laisser imposer n’importe quoi) et des décideurs (pour prendre en compte l’intérêt d’un développement bien fait sur le vite fait mal fait).

Et là j’ai un exemple rassurant, et un autre déprimant.

Le rassurant, c’est Rust, qui monte bien grâce à ses qualités (et grâce, ou peut-être malgré, ses zélotes). Il prouve qu’un langage nouveau peut percer dans l’industrie s’il a les qualités requises.

Le déprimant, c’est JavaScript, qui est l’archétype de tout ce qui est dénoncé dans ce journal. Or, il y a une quantité démente de code JS qui n’a aucun sens et qui est produit par des masses de développeurs qui semblent se complaire dans le code vite fait, mal fait, et jetable (je renvoie le lecteur curieux au cycle de vie de n’importe quel framework JS connu, ou aux libs isOdd et isEven).

PS : autre chose d’important à propos de l’industrie informatique : le client peut imposer des choix technologiques. Selon ce que tu considère et la nature du projet, ça va de « rare » à « quasi-systématique ». Par exemple, si le code est destiné à tourner sur les serveurs internes du client, on va t’imposer le système d’exploitation à utiliser, et généralement la famille technologique.

@nohar: Comme d’habitude c’est un problème d’optimisation multi-critère et il faut comprendre ses préférences personnelles et essayer de faire au mieux sur tous les tableaux à la fois.

Ce que tu dis est globalement très juste, mais tu le dis sur le ton de la contradiction, comme si c’était "rendre le monde meilleur dans une ambiance de merde" ou "exploiter les failles psychologiques de ses utilisateurs pour capter des microtransactions avec des collègues de rêve". C’est tout à fait sain de chercher un ticket pour une arche utile avec un capitaine sympa, et pas du tout contradictoire.

Le fait de servir une bonne cause peut avoir un coût, en rémunération, en horaires ou en responsabilités ressenties dans son travail…; mais encore une fois, c’est un problème d’optimisation multi-critères.

Même quand on a un profil que les recruteurs s’arrachent, on ne change pas de boulot comme de chemise.

Certainement, mais on ne trouve pas un nouveau boulot sans en chercher, et rien n’interdit d’envoyer des CVs ou de prendre contact avec des gens qui font un travail très positif, tout en restant dans son boulot préféré du moment.

Note: dans le cadre de cette discussion spécifique (sur l’état du logiciel), "rendre le monde meilleur" c’est en gros "aider les projets qui visent à nous permettre d’écrire du meilleur logiciel", ce n’est pas demander grand chose en définitive — on ne parle pas de partir dans une ONG dans un pays en voie de développement pour travailler sur des steaks de tofu humanitaire à coût carbone négatif financés par des micro-crédits.

@SpaceFox:

Enfin, le problème est général et doit trouver une solution générale ; trouver un projet et en faire son métier est une solution égoïste qui n’est pas très satisfaisante dès qu’on regarde au-delà de sa vie personnelle.

Euh, non ?

On dirait que tu conçois l’industrie par son dénominateur commun le plus ignorant et amorphe. Dans l’industrie il y a aussi des gens qui financent tous les projets que j’ai cités, par exemple. L’industrie c’est ce qu’on en fait tous, chacun, collectivement. J’écris du code qui est utilisé dans l’industrie, donc je fais partie de l’industrie. C’est très bien de chercher des solutions générales, mais ça n’est pas du tout en contradiction avec le fait de contribuer à des initiatives spécifiques qui font avancer la situation dans le bon sens — et qui existent aussi dans l’industrie, quoi que tu en dises.

Linus Torvalds était-il égoïste en créant un nouveau noyau au lieu de faire du lobbying sur Microsoft pour qu’ils améliorent le leur ? La majorité des langages et outils utilisés à grande échelle aujourd’hui à grande échelle n’ont-ils pas été créés par des hobbyistes qui voulaient en premier lieu répondre à leurs besoins personnels ?

Si tu veux devenir un gourou de la transformation agile durable de qualité disruptive, écrire des articles de blog râleurs et mal informés, ignorer ce qui se fait d’intéressant sur le sujet que tu prêches, ouvrir un compte Patreon pour financer ton travail d’évangélisation, et aller donner des exposés dans des conférences "industrielles" de programmation pour te faire applaudir par les gens qui font exactement ce que tu critiques, fais-toi plaisir. Mais est-ce vraiment "plus utile" ?

@gashe Ce n’est pas du tout ma définition de l’industrie, et tout le reste n’est qu’une spéculation sur des déformations de mes propos. Je ne vois pas la peine de tenter de répondre à ça.

Je suis complètement d’accord avec le post de blog qu’a linké @SpaceFox, cependant je ne serais pas aussi catégorique sur ce point.

Ne pas ré-utiliser du code c’est potentiellement (et même souvent à coup sûr) réécrire des choses qui fonctionnent déjà, qui ont été testées plus longuement, etc. Bref, le laïus habituel qu’on a déjà tous entendu.

En revanche, il est tout à fait vrai que l’on ré-utilise du code qui n’est pas prévu pour la tâche voulue et on met des rustines sur des rustines, on scotche les bouts qui vont pas ensembles du mieux qu’on peut, etc. Mais pour moi, le problème ici c’est pas de vouloir ré-utiliser le code. C’est plutôt que le code n’a pas été prévu pour ça à la base, et principalement parce que l’on refuse d’y investir les moyens nécessaires, parce que oui, il en faut beaucoup pour avoir quelque chose avec un pareil niveau de flexibilité.

Après, c’est vrai qu’il y a des morceaux de code qui sont spécifiques à une tâche particulière qu’on ne retrouve pas ailleurs. Mais je serai surpris que ça représente la majorité de ce qu’on a besoin d’écrire.

Pour ce qui est du post de blog en lui-même. Outre les histoires de performances qui effectivement me rendent complètement dingue, j’arrive pas à comprendre comment on en est arrivé à ce niveau. Il y a deux choses qui m’importent particulièrement:

• notre compréhension de ce que l’on fait, de ce que notre code fait,
• notre capacité par réutilisation à rendre le processus de mise à jour des systèmes invisible.

Pour le premier point, c’est pour ça que j’aime les méthodes formelles, même si ça demande un boulot de dingue. Quand on a montré formellement et avec une mécanisation de la preuve que quelque chose marche, on n’a pas pu tricher. Et au final, on est bien obligé de comprendre pourquoi ça marche.

Pour le second point, à mon avis, il découle de l’instabilité intrinsèque de nos systèmes. Je ne pige qu’aujourd’hui, on soit pas capable de déployer des mises à jour de manière invisible pour l’utilisateur, sans avoir à re-DL la quasi totalité du soft à chaque fois. Sans parler des softs en tout genre qui packents les libs avec parce qu’eux ils utilisent une version à poil long alors que le voisins utilise celle à poil court et dru, qu’il ne faut pas confondre avec celle à poil court et soyeux.

@nohar: Comme d’habitude c’est un problème d’optimisation multi-critère et il faut comprendre ses préférences personnelles et essayer de faire au mieux sur tous les tableaux à la fois.

On est d’accord. Mon message avait tendance à polariser les deux visions et donc à beaucoup simplifier les choses. Après tout la qualité de vie au travail est un vrai sujet complexe, avec des gens qui font des études pour ça (je parle bien de psychologues du travail/ergonomes/etc. Et pas des "experts en bien-être au travail/prof de tai-chi à mi-temps").

Mais pour moi, le problème ici c’est pas de vouloir ré-utiliser le code.

Non, le problème c’est de s’enfermer dans la croyance que réutiliser du code qui fait "quasiment" le job sera systématiquement meilleur et moins coûteux, là où un bon copier-coller-adapter suivi d’une refacto (une fois que les deux fonctionnent, on se gratte la tête et on isole correctement une lib commune), serait parfois plus sain pour faire les choses à la fois vite (on livre vite) et bien (on réduit/allège a posteriori avec la vraie connaissance factuelle de comment c’est utilisé dans la réalité, mais bien sûr ça demande de retravailler quelque chose qui marche…). Le problème c’est d’en tirer une echelle de valeur systématique, en fait.

@SpaceFox

Ce n’est pas du tout ma définition de l’industrie, et tout le reste n’est qu’une spéculation sur des déformations de mes propos.

C’est pourtant toi qui a écrit:

du point de vue de l’industrie, le fait de de n’avoir aucun nouveau noyau d’OS depuis 25 ans est un fait, pas une absurdité. Les choses intéressantes ne sont pas encore du domaine de l’industrie.

Je ne comprends pas comment tu peux dire ça — à moins, encore une fois, de définir "le point de vue de l’industrie" de façon extrêmement restrictive (et simpliste). Les nouveaux noyaux, ils existent bien dans l’industrie : Google Fuchsia c’est quand même vachement l’industrie, MirageOS c’est aussi l’industrie, le travail sur SeL4 est utilisé au niveau industriel (anciennement par la boîte Open Kernel Labs), etc.

Je ne vois pas la peine de tenter de répondre à ça.

Il faut savoir accepter le désaccord et les déformations dans une discussion. Je fais une blague sur les gourous agiles disruptifs et les fermes à tofu, et ça y est, c’est une insulte, plus la peine de discuter! Je ne suis pas d’accord avec le billet que tu cites et ce que tu écris, pour des raisons précises que j’explique. Tu as le droit de ne pas avoir envie de discuter/débattre et de te confronter avec un autre point de vue, mais tu ne me feras pas croire que c’est à cause de ma blague sur Patreon.

Ce sujet parle du développement informatique. C’est un sujet vaste comme le monde. Chacun a son vécu. Celui qui travaille dans une start-up, ou celui qui travaille dans une grosse boite quasi-centenaire, tous 2 vont dire que le développement informatique est mal géré, et pourrait être amélioré. Mais amélioré, pour l’un, ça veut dire 'plus orienté XXX’, et pour l’autre, ça veut dire 'moins orienté XXX' donc exactement l’inverse. Et tous 2 sont de parfaite bonne foi, et tous 2 ont probablement plus ou moins raison.

Quand on parle d’un sujet fourre-tout comme celui-ci, forcément, il y a quiproquo, incompréhension, et embrouilles.

Je vais tenter une analogie : imaginons que je poste un article sur le fait que le parc automobile français pollue trop alors qu’on a des solutions. Ce que tu viens me dire, c’est qu’il y a des gens qui roulent avec des voitures qui consomment 1 L/100 km, ou équivalent électrique.

Oui c’est techniquement vrai, tout comme Google Fuschia ou MirageOS sont techniquement partie de l’industrie informatique. Ça reste des éléments qui sont peut-être un début de solution, mais qui restent ultra-minoritaires dans l’ensemble, et que pratiquement personne ne considère comme étant partie de l’ensemble lorsqu’il s’agit d’étudier des problèmes portant sur l’ensemble, parce qu’ils ne sont pas représentatifs.

Pourquoi je refuse de continuer le débat avec toi ? Pas à cause de la blague sur Patron, mais parce que ce n’est pas la première fois que tu t’exprimes sur un tel sujet, et que tu tombes toujours dans les mêmes travers. À savoir que tu sembles considérer que les développeurs qui ne s’intéressent pas à la recherche ou aux travaux avancés ne méritent que ta condescendance. Je pèse mes mots : relis tes posts, ton vocabulaire à ce sujet est édifiant.

Je pense sincèrement que tu n’a pas la moindre idée de ce qu’est le quotidien d’un développeur lambda dans l’industrie informatique, même de bonne foi, même qui essaie de bien faire à son niveau. Si c’était le cas, je doute que tu utiliserais des termes tels que « milieu "mainstream" fermé d’esprit » ou dire « absurdité » quand l’auteur décrit ce qui est une réalité de fait pour la grande majorité des développeurs (et ce n’est pas avoir une définition « extrêmement restrictive (et simpliste) » de ce qu’est l’industrie informatique de dire ça, simplement du pragmatisme¹). Ce que tu appelles « se renseigner sur les projets qui font des efforts pour avancer l’état de l’art » à ton niveau, c’est probablement des fantasmes impossibles à mettre en place pour la majorité des développeurs.

La grande différence avec d’habitude, c’est que là je suis de mauvaise humeur.

Je trouve que cet article mélange pas mal de choses ensembles et du coup cela n’aide pas à bien définir le sujet du débat.

Par exemple, il compare souvent des situations de manières très fortement biaisées. Comparer la taille de W95 avec une application Android moderne n’a je pense pas un grand intérêt. Pourtant je trouve que récemment pas mal de gens se plaignent que si la performance des machines augmentent, les gens ne visualisent pas où cette performance est consommée. Pourtant en 20–25 ans, même si on utilise l’ordinateur de façon similaire ça a pas mal changé.

Reprenons W95. Déjà toute l’interface était moche, en couleur 16 bits dans une résolution où le moindre pixel était largement visible. Ça crashait pour un oui ou un non, bien plus que les applications modernes dont Windows 10. Internet Explorer n’était pas fourni par défaut, et je pense que vous imaginez bien que la gueule des sites web a évolué aussi.

Cela manipulait des fichiers légers. Des petites vidéos, photos ou des GIF tout au mieux quand aujourd’hui on peut afficher des vidéos en 4K sans broncher (merci les accélérateurs matériels et la qualité des formats moins naïfs aujourd’hui). La cryptographie s’impose partout également, ce qui ajoute forcément des conceptions plus complexes et des instructions supplémentaires.

W95 était sans doute bien pour un européen ou nord américain, car niveau traduction ou prise en charges des alphabets non latin ce n’était pas non plus terrible par rapport à aujourd’hui. La diversité des architectures et des périphériques a considérablement évolué. W95 était juste bon à fonctionner sur x86 avec quelques imprimantes et composants compatibles. Et forcément quand on veut de la généricité, faut faire des couches d’abstraction ce qui a un coût. Et l’USB ou PCIe ont une complexité de fou par rapport aux standards de l’époque, mais ça a un gain énorme en souplesse pour l’utilisateur et les fabricants aussi.

W95 gérait l’énergie comme une merde car en fait… il ne faisait rien (ou presque). Pour que certains jeux fonctionnent bien, il fallait appuyer sur le bouton "Turbo" à l’époque pour réduire les perfs mais avoir le bon timing de fonctionnement pour le jeu. Et il fallait à l’époque faire des binaires spécialement pour PAL ou NTSC car la synchronisation se basait dessus. Pas top quoi. Aujourd’hui l’OS pilote de concert avec le processeur la consommation énergétique pour allier perfs / conso. Ce n’est pas gratuit non plus. Sans compter que Windows isole aussi maintenant les applications ou pilotes pour être plus fiable, ce n’est pas gratuit.

W95 c’était aussi un OS où la ligne de commande n’était jamais très loin. Les applications avaient une application assez mauvaise aussi par rapport aux standards d’aujourd’hui. Et oui les petites animations graphiques ça consomme un peu, peut paraître lourdingue mais cela aide aussi l’utilisateur dans l’utilisation du programme.

Et aujourd’hui on est capable de virtualiser tout et n’importe quoi avec nos machines. Opération à l’époque très coûteuse et difficile à mettre en œuvre.

Et pour tenir dans des machines aussi faiblardes, je doute que le code de l’époque soit aussi lisible que celui d’aujourd’hui. Donc on optimise un peu moins pour la machine mais on optimise la fiabilité et l’évolution future du code.

Etc.

Et le soucis c’est que dans son argumentaire, on pourrait parler de cela pour pas mal de ses exemples ainsi. Ce qui réduit je trouve la portée de son argumentaire.

Même si le Software Craftmanship et les améliorations autour de soi sont utiles, la vraie question qui découle de tout ça est : comment provoquer une prise de conscience généralisée des problèmes du développement actuel et donc comment modifier tout ça au niveau de l’industrie ?

A mon avis, un début de solution viendrait en rendant les entreprises responsables du point de vu sécurité.

Sans parler RGPD qui a des avancés sur ce sujet pour la vie privée (mais que je ne maîtrise pas assez pour me prononcer dessus), si la boite X développe un firmware pour un objet connecté quelconque et que celui ci se retrouve piraté à cause de "fautes graves" (à démontrer) et qu’elle doit payer k euros par objet piraté aux victimes de DDOS, ca motiverait sûrement des changements d’outillage.

Je suis dans un projet européen qui vise à amener les méthodes formelles dans le monde de l’IoT pour les aspects sécurité (avec un focus sur les problèmes "simples" : absence de runtime errors typiquement). J’ai jamais eu autant l’impression, depuis que j’ai commencé dans ce domaine, de m’attaquer à un défi perdu d’avance parce que les acteurs s’en tapent royalement d’avoir du niveau de sécurité de leurs devices*, et parce que ça va aboutir à une norme qui ne sera utilisée qu’en "auto-certification" donc autant dire : "oui, oui, bien sûr qu’on a fait … hum … ce qui est écrit".

* et aussi parce que c’est du code legacy de pile réseau et de fin fond d’OS atroce.

@Ksass`Peuk > ca illustre bien mon point. Si tu es deviens responsable financièrement avec de grosses sommes en jeu, tu es incité à changer de langage, utiliser les méthodes formelles.

Semi HS: je pense d’ailleurs que les méthodes formelles qui visent à prévenir certaines erreurs de runtime (typiquement pointeur null, accès hors bornes) sont du sparadrap sur une jambe nécrosée et que ce genre d’erreurs disparaîtra avec un meilleur langage.

Pour le HS :

Semi HS: je pense d’ailleurs que les méthodes formelles qui visent à prévenir certaines erreurs de runtime (typiquement pointeur null, accès hors bornes) sont du sparadrap sur une jambe nécrosée et que ce genre d’erreurs disparaîtra avec un meilleur langage.

Le fait est que la jambe, toute nécrosée qu’elle soit, est encore bien utile à ceux qui l’utilisent et que leur greffer une jambe neuve ne serait pas toujours une meilleure idée (par exemple parce que ça prend beaucoup de temps, pendant lequel la jambe nécrosée ferait mieux d’avoir du sparadrap).

Tout en travaillant sur ces méthodes formelles automatiques qui cherchent à prévenir des erreurs qu’on aurait sans doute pu éviter avec un meilleur typage (mais qui vont quand même un peu plus loin que les pointeurs nuls), je pense que la meilleure méthode pour avoir confiance en un programme qu’on écrit de zéro, c’est de concevoir cette confiance (donc une preuve de correction) en même temps que le programme, en utilisant des outils comme Coq pour écrire du code certifié. Les analyses statiques a posteriori seront mathématiquement limitées en expressivité, et en plus de ça elles ne peuvent pas deviner l’intention que le programmeur avait en écrivant son code, ce qui lui demande d’écrire les annotations qui vont bien s’il veut avoir des garanties un peu plus forte que « c’est bon ce filtre ne va jamais overflow ».

L’ennui de ces méthodes de certification, c’est précisément qu’elles exigent d’être utilisées depuis le début, en même temps que l’écriture du programme lui-même. Et donc ça ne marche pas vraiment pour des programmes qui existent déjà, soit parce qu’ils ont été conçus il y a longtemps, soit parce qu’au début on ne s’attendait pas à avoir besoin de ce genre de garanties (par exemple en s’imaginant que les tests ça suffisait et qu’on pouvait avoir confiance en des métriques un peu ad-hoc comme la couverture du code). Et comme en fait, les tests ça ne marche pas parce que c’est long et que ça oublie toujours des comportements, il faut bien une méthode formelle un peu plus évoluée. Alors bien sûr ça ne sera jamais aussi expressif qu’une preuve du programme à la main (ou assistée, ce qui revient au même), mais ça a l’avantage de s’appliquer directement (presque) avec un outil déjà conçu sur du code déjà écrit. Et on peut déjà faire beaucoup de choses avec ça.

On notera aussi que même écrire en Coq, ça ne change rien au fait que lorsque l’on amène les programmes vers le code machine, il faut encore montrer que l’on préserve bien la sémantique jusqu’au binaire. Et ça a, à l’heure actuelle, c’est pas encore tant réalisé que ça.

Pas seulement. Les preuves sont très souvent sensible au moindre petit changement. Et parfois comprendre ce qui passe ou ne passe plus peut demander un temps considérable. Et pour le moment, ces méthodes ne sont accéssibles qu’à des experts en général même si on tend vers une simplification de l’utilisation de ces outils.

Et ça ne suffit pas, qui te dit que le hardware est correct ? Que l’OS ne vas pas faire de bêtise avec ton binaire ? etc… De toute façon, il est impossible d’avoir une confiance absolue du début à la fin, cette confiance sera toujours relative.

Là je pense que c’est toi qui ne sait pas de quoi tu parles. Oui, ça à un coût de se renseigner sur l’État de l’art, mais il n’est pas si énorme que ça. Surtout que cela peut éviter de reproduire des erreurs qui sont déjà connues. Lorsque j’ai fait un séjour à McGill, j’étais très content de voir des industriels se pointer à un workshop consacré aux langages de programmation et systèmes de types. C’était l’occasion pour eux de parler de leur projet et d’intéragir avec le monde de la recherche. Et ses intéractions étaient assez positives car il ne fallait pas tant de temps que ça pour comprendre ce qu’ils faisaient. Cela leur permettait en retour de comprendre ce qui pouvait fonctionner ou pas et de faire connaître leur projet.

De ma maigre expérience, les chercheurs sont facilement accéssibles et envoyer un mail ne coûte pas grand chose. En retour, si le projet est dans les cordes du chercheur, ce dernier trouvera toujours du temps pour en parler, sinon en général il pourra toujours rediriger la personne vers d’autres chercheurs plus compétent. Quand je vois que Jonathan Blow invente un nouveau langage Jai, j’espère c’est ce qu’il a fait avant de partir tête baissée dans ce projet.

Le mot-clé est « mettre en place ». Parler aux chercheurs, aller à des confs, et comprendre ce dont il s’agit c’est la partie facile. La partie problématique, c’est d’implémenter ça dans des projets réels. Donc convaincre les décideurs, etc. Les exemples de solutions technologiques cool qui auraient pu être implémentés, mais ça ne s’est jamais fait parce que :

• « c’est [trop] cher » (c’est relatif),
• « on a pas le temps » (tu ne veux pas le prendre),
• « c’est pas utilisé ailleurs » (argument malheureux mais fréquent du décideur qui n’a pas envie d’essuyer de plâtres quitte à rester 15 ans en arrière),
• « on va essayer ça sur un petit projet » (qui n’arrive souvent pas en prod ou qui n’est jamais généralisé),
• « on voit pas l’intérêt » (… alors qu’en général on vient de l’expliquer),
• « ça n’est pas rentable » (si, mais comme tu es incapable de voir à plus de trois mois, ça te passe au-dessus de la tête),
• « c’est trop compliqué pour l’équipe » (si tu prends les gens pour des clowns ou ne recrute que ça, tu as en effet une équipe de clowns),
• sa variante « on ne va pas former les gens sur ça » (pourquoi pas ?),
• et sa variante subtile « on a pas besoin d’un truc si compliqué / avancé » (en général ça ne l’est pas, si compliqué que ça, et on vient de t’expliquer en quoi c’est utile),
• « ça a l’air bien mais on verra ça plus tard » (généralement jamais),
• « d’accord, mais tu fais passer ça dans le budget initial » (ha ?)
• et sa variante « tu fais ça sur ton temps personnel » (heu… non ?),
• « le client ne va jamais accepter ça » (si on ne lui demande pas, il n’y a effectivement aucune chance qu’il accepte – en admettant qu’il ait réellement son mot a dire),
• « mouais, je ne le sens pas » (… mais déjà entendue),
• « ça n’est pas compatible avec notre stack » (généralement alors que l’adaptation à faire est minime),
• « on a une expertise en XXX, ça n’est pas XXX, donc on ne va pas faire » (mais si tu ne fais pas évoluer ton expertise, elle risque bien de devenir obsolète),
• « on a déjà YYY, on ne va pas le jeter » (on rejoint le problème de la mauvaise réutilisation déjà évoqué).

Ce ne sont pas des exemples en l’air, ce sont tous des « arguments » que j’ai déjà entendus, et certains sont des classiques dans les projets que j’ai croisés personnellement ou via des connaissances. C’est valable quelle que soit la taille de l’entreprise, quelle que soit sa fonction (SSII, éditeur, client final, équipes de développement chez les clients…), et sur toutes sortes de technologies (bien que principalement du développement web au sens large ou mobile). Seules les équipes qui font de la R&D orientée informatique avec une réelle partie recherche semblent à peu près épargnées par ce genre de considérations, parce qu’elles semblent mieux comprendre les enjeux d’une bonne conception.

Et ça c’est en admettant que tu aies réellement accès à de la veille technologique, à des chercheurs, etc. Il y a beaucoup d’entreprises qui partent du principe que tout ça tu dois le faire sur ton temps perso, et beaucoup de développeurs qui n’ont plus rien à battre de l’informatique une fois sortis du boulot (demander « Comment vous tenez-vous au courant de l’actualité informatique » en entretien amène des réponses édifiantes). Ça aussi c’est un gros problème du secteur, d’ailleurs, et je pense qu’il n’est pas totalement découplé de celui décrit dans l’article.

J’en profite pour noter que l’excès inverse, à savoir « on choisit la technologie Bidule parce qu’elle est à la mode et tout le monde en fait », et ce sans chercher à savoir si elle est adaptée au projet, est lui aussi fréquent et tout aussi dévastateur.

Edit : typo

Pour info, le billet a été traduit en français ici : https://blog.romainfallet.fr/desenchantement-logiciel/