[Écologie] Le monde du logiciel est en train de se détruire... Manifeste pour... - 0 views
-
Tout est lent, et cela ne va pas dans le bon sens. Certaines voix s’élèvent. Je vous invite notamment à lire “Le désenchantement du logiciel”. Tout est insupportablement lent, tout est ÉNORME, tout finit par devenir obsolète… La taille des sites web explose. Un site web est aussi gros que le jeu Doom. Le phénomène ne touche pas que le Web mais aussi l’IoT, le mobile… Le saviez-vous ? Il faut 13% de CPU pour faire clignoter un curseur…
-
Tout grossit : la taille des applications, les données stockées, la taille des pages web, la mémoire des téléphones… Les téléphones ont maintenant 2 Go de mémoire, échanger une photo de 10 Mo par mail est maintenant classique… À la limite, cela ne serait peut-être pas un problème si tous les logiciels étaient utilisés, efficaces et performants… Mais cela n’est pas le cas,
-
Alors tout le monde se cale sur une lenteur. Tout est uniformément lent. On se cale sur cela et tout va bien. Être performant aujourd’hui, c’est arriver à atteindre un ressenti utilisateur qui correspond à cette lenteur uniforme. On élague les choses qui pourraient être trop visibles. Une page qui met plus de 20 secondes à se charger, c’est trop lent. Par contre, 3 secondes c’est bien. 3 secondes ? Avec les multicoeurs de nos téléphones/PC et les data centers partout dans le monde, le tout relié par des supers technologies de communication (4G, fibre…),c’est un peu bizarre non ? Si on regarde la débauche de ressources pour le résultat obtenu, 3 secondes, c’est énorme. D’autant plus que les bits circulent dans nos processeurs avec des unités de temps du niveau de la nanoseconde. Donc oui, tout est uniformément lent.
- ...29 more annotations...
-
Il est nécessaire de revenir à plus d’efficience, de « challenger » les besoins en matériel, de redéfinir ce qu’est la performance. Tant que l’on se satisfera de cette lenteur uniforme avec des solutions pour ne pas ralentir plus (comme l’ajout de matériel), nous n’avancerons pas. La dette technique, notion largement assimilée par les équipes de développement, n’est malheureusement pas adaptée à ce problème (on y reviendra). Nous sommes sur une dette de ressources matérielles et de mauvaise adéquation entre le besoin utilisateur et la solution technique. On parle ici d’efficience et non pas uniquement de performance. L’efficience est une histoire de mesure du gaspillage. L’ISO définie l’efficience avec comme domaine : Time behaviour, Resource utilization et Capacity. Pourquoi ne pas pousser plus ces concepts ?
-
Développez du code Java pour un serveur J2EE ou pour un téléphone Android, ce n’est pas pareil. Des structures spécifiques existent par exemple pour traiter des données en Android mais les structures classiques sont toujours utilisées. Les développeurs ont perdu le lien avec le hardware. C’est malheureux car c’est passionnant (et utile) de savoir comment fonctionne un processeur. Pourquoi : abstraction et spécialisation (nous verrons cela plus loin). Car en perdant ce lien, on perd une des forces du développement. Ce lien est important chez les hackers ou chez les développeurs d’informatique embarquée mais malheureusement de moins en moins présent chez les autres développeurs.
-
Les pratiques devops pourraient répondre à cette perte de lien. Là, c’est pareil, nous n’allons pas jusqu’au au bout : généralement le devops va se focaliser à bien gérer le déploiement d’une solution logicielle sur une infrastructure mixte (matérielle et un peu logicielle). Il faudrait aller plus loin en remontant par exemple les métriques de consommation, en discutant sur les contraintes d’exécution… plutôt que de “scaler” juste parce que c’est plus simple.
-
Certaines technologies ont une utilité mais sont maintenant systématiquement utilisées. C’est le cas par exemple des ORM qui sont devenus systématiques. Aucune réflexion n’est faite sur son intérêt en début des projets. Résultat : on a rajouté une surcouche qui consomme, qu’il faut maintenir et des développeurs qui n’ont plus l’habitude d’effectuer des requêtes natives. Cela ne serait pas un problème si chaque développeur connaissait très bien le fonctionnement des couches d’abstraction : comment fonctionne HIBERNATE par exemple ? On s’appuie hélas de façon aveugle sur ces frameworks.
-
Le besoin d’abstraction est lié à un autre défaut: nous attendons toujours des outils miracles. La silver bullet qui améliorera encore plus nos pratiques. Le langage idéal, le framework pour aller plus vite, l’outil de gestion miracle des dépendances… C’est la promesse à chaque fois d’un nouveau framework : gagner du temps en développement, être plus performant… Et on y croit, on fonce. On abandonne les frameworks sur lesquels nous avions investi, sur lesquels on avait passé du temps… et on passe au nouveau. C’est le cas actuellement des frameworks JS. L’histoire du développement est pavé de framework oubliés, non maintenus, abandonnés… Nous sommes les champions pour réinventer ce qui existe déjà. Si on le gardait suffisamment longtemps, on aurait le temps de maîtriser un framework, de l’optimiser, de le comprendre. Mais ce n’est pas le cas. Et que l’on ne me dise pas que si on n’avait pas continuellement réinventé la roue, on aurait encore des roues en pierre… Innover serait d’améliorer les frameworks existants .
-
Sur les langages, c’est la même rengaine. Attention, je ne préconise pas de rester sur l’assembleur et sur le C… C’est le cas par exemple dans le monde Android, pendant plus de 10 ans les développeurs ont pu travailler sur des outils et des frameworks Java. Et comme cela, par magie, le nouveau Langage de la communauté est Kotlin. On imagine l’impact sur les applications existantes (si elles doivent changer), il faut recréer des outils, retrouver des bonnes pratiques… Pour quel gain?
-
Sincèrement, on ne voit aucun ralentissement sur les cycles de renouvellement des technologies. C’est toujours un rythme frénétique. Nous trouverons bien le Graal un jour. Le problème est ensuite l’empilement de ses technologies. Comme aucune ne meurt vraiment et que l’on en maintient toujours des parties, on développe d’autres couches pour s’adapter et continuer à maintenir ces bouts de code ou ces librairies. Le problèmen’est pas le code legacy,, c’est la glue que l’on développe autour qui pêche.
-
Au final, on passe du temps à résoudre des problèmes techniques internes, on recherche des outils pour résoudre les problèmes que l’on ajoute, on passe son temps à s’adapter à ses nouveaux outils, on ajoute des surcouches (voir chapitre précédent…) … et on n’a pas améliorer la qualité intrinsèque du logiciel ou les besoins auxquels on doit répondre.
-
Au final, le rythme frénétique des changements ne nous permet pas de nous stabiliser sur une technologie. J’avoue qu’en tant que vieux développeur que je suis, j’ai été découragé par le changement Java vers Kotlin pour Android. C’est peut-être pour certains de véritables challenges, mais quand je repense au temps que j’ai passé sur l’apprentissage, sur la mise en place d’outils
-
Ensuite, comme aucune solution ne meurt vraiment, que de nouvelles arrivent… on se retrouve avec des projets avec des multitudes de technologies à gérer avec les compétences associées aussi… On s’étonne ensuite que le marché du recrutement de développeur soit bouché. Pas étonnant.. Il y a énormément de développeurs mais il est difficile de trouver un développeur React avec 5 ans d’expérience qui connaîsse le Go. Le marché est fractionné, comme les technologies. C’est peut-être bon pour les développeurs car cela crée de la rareté et cela fait monter les prix, mais pas pour le projet !
-
Cependant, cet apprentissage continu des technologies pose le problème d’apprentissage de domaines transverses : accessibilité, agilité, performance… En effet, qu’est-ce qui nous prouve que les outils et les langages que nous allons choisir ne vont pas changer dans 4 ans ? Rust, Go… dans 2 ans ? Rien ne tend à donner une tendance.
-
On ne se remet pas en question car on veut s’amuser. Le fun est important, car si l’on s’ennuie dans son boulot, on va déprimer. Par contre, on ne peut pas, sous prétexte de vouloir du fun tout le temps, changer nos outils continuellement. Il y a un déséquilibre entre l’expérience du développeur et l’expérience de l’utilisateur. On veut du fun, mais qu’est-ce que cela va réellement apporter à l’utilisateur ? Un produit plus « joyeux » ? Non, nous ne sommes pas des acteurs.
-
On ne se pose pas de question sur l’éthique de notre domaine, sur sa durabilité… Cela vient peut-être du fait que notre domaine n’a pas réellement de code éthique (comme par exemple les médecins ou les avocats). Mais sommes-nous en tant que développeurs réellement libres si l’on ne peut pas avoir une autocritique ? Nous sommes peut être asservis à une cause portée par d’autres personnes ? Le problème n’est pas simple mais nous avons dans tous les cas une responsabilité. Sans code éthique, c’est le plus fort et le plus malhonnête qui est le plus fort. Le buzz et les pratiques pour manipuler les utilisateurs sont de plus en plus répandus. Sans Dark Pattern ton produit ne sera rien. Les plus gros (GAFA…) n’en sont pas arrivés là pour rien.
-
Est-ce que la solution est politique ? Il faut légiférer pour mieux gouverner le monde du logiciel. On le voit avec les dernières réponses législatives aux problèmes concrets : RGPD, notification des cookies… la source du problème n’est pas résolue. Peut-être parce que les politiques ne comprennent que très mal le monde du logiciel.
-
Car si cette structuration n’est pas faite, les développeurs vont perdre la main sur ce qu’ils font. Or le manque d’éthique de la profession est critiqué à l’extérieur. Rachel Coldicutt (@rachelcoldicutt) directrice de DotEveryOne, un think tank britannique qui promeut une technologie plus responsable, encourage à former des diplômés non-informaticiens qui traiteraient de ces problèmes (Voir plus précisément dans l’article d’Internet Actu). Pour poursuivre sur ce dernier article, cela serait dans la droite ligne de l’informatique, domaine issu du monde militaire où les ingénieurs et développeurs seraient formés à suivre des décisions et des commandements.
-
Le monde du logiciel s’intègre dans un système organisationnel classique. Grands groupes, sous-traitances via des ESN, web agencies… Tous suivent les mêmes techniques de gestion des projets informatiques. Et tout le monde va « dans le mur ». Aucune analyse sérieuse n’est faite sur le coût global d’un logiciel (TCO), sur son impact sur la société, sur son bénéfice, sa qualité… C’est la rapidité de release(Time to Market), la surcharge featurale (fonctionnelle), la productivité immédiate, qui comptent. Premièrement car les gens externes à ce monde ne connaissent que trop peu la technicité du logiciel et son monde. Il est virtuel donc simple (sic). Mais ce n’est pas le cas. Les écoles de commerce et autres usines de managers n’ont pas de cours de développement. Comment peuvent-ils bien diriger et piloter des projets ?
-
On continue a vouloir chiffrer des projets informatiques comme de simples projets alors que des mouvements comme le no estimate propose des approches innovantes. Les projets continuent d’échouer : le chaos report rapporte que simplement 30% des projets réussissent bien. Et face à cette mauvaise gouvernance, les équipes techniques continuent de se battre sur les technologies. Dommages collatéraux : la qualité, l’éthique, l’environnement… et au final l’utilisateur. Cela ne serait pas si critique si le logiciel n’avait pas un impact aussi fort sur le monde. Software eats the world… et oui, on le « bouffe »…
-
Si ces décisions absurdes arrivent, ce n’est pas uniquement la faute du développeur mais bien de l’organisation. Et qui dit organisation dit management (sous-différente forme). Si l’on revient au livre de Morel, il parle de piège cognitif dans lesquels les managers et les techniciens tombent souvent. C’est le cas de la navette Challenger qui a été quand même lancée malgré la connaissance du problème d’un joint défectueux. Les managers ont sous-évalué les risques et les ingénieurs ne les ont pas prouvés. Chacun a reproché à l’autre de ne pas fournir assez de preuves scientifiques. C’est souvent ce qui se passe dans les entreprises : des warnings sont levés par certains développeurs mais le management ne les prend pas assez au sérieux.
-
En même temps, on revient aux causes précédentes (silver bullet, on s’amuse…), il est nécessaire d’avoir une vraie ingénierie et une vraie analyse des technologies. Sans cela, les équipes techniques seront toujours non-écoutées par le management. Des outils et benchmark existent mais ils sont encore trop peu connus. Par exemple, Technologie Radar qui classe les technologies en terme d’adoption.
-
Ce phénomène de décision absurde est renforcé par le tissu complexe du développement logiciel : Les sociétés historiquement hors du numérique sous-traitent à des entreprises du numérique, les ESN sous-traitent aux freelances… Le partage de responsabilité technique / management est encore plus complexe et les décisions absurdes plus nombreuses.
-
Mais cela ne s’arrête pas là. On peut aussi voir l’usage de l’open-source comme une sorte de sous-traitance. Idem pour l’usage de framework. On est juste consommateur passif, on se déleste de plein de problématiques (qui ont un impact sur les ressources, la qualité…).
-
C’est d’autant plus facile que le domaine est passionnant et que la pratique des sides-projects, du temps passé sur les projets open-source hors des horaires de bureau est chose commune… La recherche de “fun” et le temps passé bénéficient alors plus aux organisations qu’aux développeurs. Difficile dans ce cas de chiffrer le coût réel d’un projet. Et pourtant, cela ne serait pas un problème si on arrivait à des logiciels « au top ».
-
Le développeur n’est ici plus un artisan du code, mais plutôt un pion dans un système critiquable du point de vue humain. Cela n’est pas visible, tout va bien et on s’amuse. En apparence seulement, car certains domaines du développement logiciel vont plus loin et rendent beaucoup plus visible cette exploitation : Le domaine du jeux-vidéo où les heures explosent.
-
Et donc, toutes ces maladresses (logiciel trop lourd, sans qualité…) se retrouvent chez les utilisateurs. Comme on doit releaser au plus vite les logiciels, que l’on ne tente pas de résoudre les inefficiences internes, et que l’on ne met pas plus de ressource pour faire de la qualité, on arrive à des logiciels médiocres. Mais on a tellement d’outils de monitoring et de suivi des utilisateurs pour détecter ce qui se passe directement chez eux qu’au final, on pense que ce n’est pas grave. Cela serait une bonne idée si les outils étaient bien utilisés. Or la multitude d’informations récoltées (en plus des bugs remontés par les utilisateurs) n’est que faiblement utilisée. Trop d’information, difficulté de cibler la vraie source du problème… on s’y perd et au final, c’est l’utilisateur qui trinque. Tous les logiciels sont maintenant en bêta-test. A quoi bon faire de la sur-qualité, autant attendre que l’utilisateur le demande. Et on revient ainsi au premier chapitre : un logiciel uniformément lent … et médiocre.
-
Heureusement, on est sauvé par la non-sensibilisation des utilisateurs au monde du logiciel. C’est un monde effectivement virtuel et magique qu’ils ont l’habitude d’utiliser. On leur a mis en main les outils mais sans notice explicative. Comment évaluer la qualité d’un logiciel, les risques sur l’environnement, les problèmes de sécurité… si l’on n’a pas des notions d’informatique, même rudimentaires ?
-
L’informatique du 21ème siècle est ce que l’agroalimentaire était pour les consommateurs au 20ème siècle. Pour des raisons de productivité, on a poussé des solutions médiocres avec un calcul court-termiste : mise sur le marché de plus en plus rapide, profit en hausse constante… agriculture intensive, malbouffe, pesticides… avec des impacts importants sur la santé, sur l’environnement… Les consommateurs savent maintenant (de plus en plus) les conséquences désastreuses de ces dérives, l’industrie agroalimentaire doit donc se réinventer, techniquement, commercialement et éthiquement. Pour le logiciel, quand les utilisateurs comprendront les tenants et les aboutissants des choix techniques, l’industrie du logiciel devra gérer les mêmes problèmes. En effet, le retour au bon sens et aux bonnes pratiques n’est pas une chose simple pour l’agroalimentaire. Dans l’IT, on commence à le voir avec ses conséquence sur la vie privée des utilisateurs (mais nous n’en sommes qu’aux balbutiements).
-
On va dans la mauvaise direction. L’industrie de l’informatique a déjà effectué dans les années 70 des erreurs avec des impacts non-négligeables. L’exclusion des femmes de l’informatique en fait partie. Non seulement cela a été fatal pour certaines industries mais on peut se poser la question de comment on peut maintenant adresser des réponses à seulement 50% de la population informatique, avec une représentativité très faible. Le chemin est maintenant difficile à retrouver.
-
Mais l’impact du monde IT ne s’arrête pas là. La source et le modèle d’une grosse partie de l’informatique sont issus de la Silicon valley. Si l’on écarte les gagnants de la Silicon Valley, les populations locales subissent la montée des prix, le déclassement, la pauvreté…
-
Dans sa lancée vers le progrès technique, le monde du logiciel crée aussi sa dette environnementale…
-
"Le monde du logiciel va mal et si l'on n'agit pas, on risque de le regretter. Environnement, qualité, exclusion… Software Eats The World (Le logiciel mange le monde…) ? Oui un peu trop. "
