La marchandisation ratée du travail technique
(ludic.mataroa.blog)- Les attentes des directions et des éditeurs sont fortes autour de l’idée de standardiser le travail technique comme une usine pour en faire un résultat reproductible, mais sur le terrain, beaucoup d’équipes ne parviennent toujours pas à le transformer de manière fiable en produit marchand
- Le fonctionnement à la McDonald's ressemble moins à une question de qualité intrinsèque qu’à une discipline permettant à des lieux et à des équipes différentes de produire le même résultat, et de nombreux ouvrages de management envisagent aussi les opérations IT sous cet angle de flux de production
- La vente de logiciels d’entreprise tient largement à la promesse de remplacer les tâches liées au SQL, aux données et au développement par du drag-and-drop et des interfaces cohérentes, afin de rendre les effectifs interchangeables
- Dans les organisations réelles, de mauvaises licences logicielles et des abstractions mal conçues ne résolvent pas les problèmes techniques ; au final, ce sont souvent d’excellents ingénieurs qui doivent corriger eux-mêmes les mauvais modèles de données et les mauvaises décisions techniques
- Les activités qui exigent créativité, goût, expertise et liens humains ne se réduisent pas entièrement à un tableau Jira ou à des points Agile, et même dans de grandes infrastructures de production, ce sont encore des individus qui font tourner le système
McDonald's montre la difficulté de la standardisation
- Le premier manager de l’auteur, excellent data engineer, était aussi quelqu’un de profondément passionné par la cuisine et il a souvent souligné la complexité des opérations de McDonald's
- La valeur de McDonald's ne réside pas tant dans la qualité du produit lui-même que dans l’optimisation et la discipline qui permettent à des employés de niveaux de formation et de régions différents de préparer le même burger
- Faire en sorte qu’une main-d’œuvre peu qualifiée, répartie sur différents sites, produise un résultat constant n’a rien de simple, et cet exemple mène à la question de la marchandisation du travail technique
Les livres de management traitent l’IT comme une usine
- The Phoenix Project présente les opérations IT comme un problème proche de celui d’une usine de fabrication, en mettant au centre les flux de travail et la gestion de la communication dans l’organisation
- Dans une veine similaire, on trouve The Unicorn Project, Investments Unlimited, The Goal
- The Goal raconte la transformation d’une véritable usine et est présenté comme l’œuvre qui a inspiré les autres livres
- High Output Management prend aussi l’exemple du fonctionnement d’un restaurant pour expliquer le flux de travail : si l’on fait bouillir les œufs au mauvais moment, les tartines auront refroidi lorsqu’elles arriveront au client
- Dans cette famille de pensée, des thèmes comme les économies d’échelle, le throughput et le flux de travail reviennent sans cesse
Le cœur du pitch des éditeurs, c’est moins la technologie que l’interchangeabilité
- Lors d’une conférence d’un éditeur, plusieurs présentations produits mettaient moins l’accent sur les détails techniques que sur la promesse de livrer de façon reproductible des résultats de travail suffisamment bons
- Un produit en particulier se vantait de permettre de configurer des dépendances avec un éditeur en drag-and-drop, sans écrire directement de SQL
- En réalité, comme l’application se connecte à Postgres, le SQL ne disparaît pas ; une couche d’abstraction sous licence l’écrit simplement à sa place
- Pour une direction, ce type de pitch peut sonner comme la promesse de remplacer un “SQL lent et source de problèmes” par une interface cohérente et des experts du marché, afin de fluidifier la circulation des données dans l’organisation
- La manière dont Agile est souvent mis en œuvre dans des organisations dysfonctionnelles ordinaires révèle un problème similaire
- On y compte les ingénieurs comme des machines, les livrables comme des pièces, les story points comme des unités de production, puis on vérifie si l’objectif de la semaine suivante a été atteint
Pourquoi une grande partie du travail technique n’a toujours pas été marchandisée
- McDonald's parvient en général à servir des frites d’une qualité prévisible en moins de cinq minutes, alors que beaucoup d’organisations techniques achètent de mauvaises licences logicielles sans réussir à déployer quoi que ce soit d’utile
- La manière la plus proche de résoudre des problèmes techniques et de mauvais modèles de données avec de l’argent consiste à s’assurer les services d’excellents ingénieurs entièrement concentrés sur la résolution des problèmes
- Même dans des domaines qui semblent se prêter à la marchandisation, on a souvent affaire en pratique à une combinaison d’entreprises qui vendent des produits qui ne fonctionnent pas et de décideurs ignorants qui les achètent
- Certains décideurs peuvent aussi choisir, au nom de la conformité juridique, de recourir à une assistance téléphonique située dans des régions à bas salaires, sans se soucier des clients qui veulent résilier
- L’auteur raconte même qu’au moment de joindre le support, il essaie d’abord d’appeler la ligne commerciale pour voir s’il peut être rapidement mis en relation avec un interlocuteur local ayant un vrai pouvoir d’action
Dans le travail technique créatif, la dimension humaine demeure
- Hammock Driven Development de Rich Hickey décrit un mode de travail où l’on nourrit son inconscient avec la recherche, puis où l’on médite et dort pour faire émerger des réponses de conception
- Les programmeurs font souvent l’expérience d’avoir la solution en prenant de la distance avec le problème, ce qui n’a rien à voir avec une activité consistant simplement à sortir des widgets plus vite
- Il existe beaucoup d’activités sociales qui consistent à produire plus vite, mais nombre de résultats de valeur naissent au point de rencontre entre une créativité difficile à définir et les réalités de la production
- Que l’on parle de livres, de cuisine ou d’exploitation de restaurant, on peut raffiner la production de masse et les systèmes de livraison, mais les beaux résultats exigent aussi du goût et de l’attention
- Même si l’on essaie de réduire le développement produit à des tableaux Jira et à des récits Agile, il est difficile d’obtenir des résultats de valeur sans lien avec les personnes
- Comme dans le cas d’une connaissance qui conçoit des puces pour l’iPhone, même avec des tests et une infrastructure de production de masse, un individu précis peut jouer un rôle si important que, s’il tombe malade, la release suivante peut être retardée
- La société fonctionne certes sur des formes de marchandisation, mais on ne peut pas faire tourner le travail technique avec une marchandisation pure qui ignorerait la compréhension d’un artisanat donné ainsi que la complexité, les besoins et les vulnérabilités humaines
1 commentaires
Avis sur Hacker News
Je pense que l’auteur passe à côté du fait qu’une grande partie de ce qu’on appelait autrefois du travail technique est désormais devenue un produit générique
Autrefois, le publipostage consistait vraiment à imprimer des tas d’étiquettes d’adresse et à les coller à la main sur des lettres et des enveloppes ; Word 2.0, autour des années 1990, a résolu ce problème, puis MailChimp l’a transformé en produit au XXIe siècle
La comptabilité en partie double était elle aussi un travail technique effectué par des personnes hautement qualifiées, mais aujourd’hui un commerçant scanne un code-barres et le client paie sans contact
Il n’existe toujours pas d’interface en glisser-déposer utilisable pour quelque chose de plus complexe que Scratch, mais la partie difficile n’est pas le travail technique consistant à assembler des bibliothèques : c’est la collecte des exigences
Intégrer une bibliothèque de chiffrement de qualité, ajouter une carte interactive à un site web, ou éditer un site web en WYSIWYG n’a jamais été aussi facile
L’auteur a raison sur le fait qu’on ne peut pas asseoir un ado de 18 ans qui s’ennuie devant un IDE et lui faire construire un ERP, mais une grande partie des tâches ingrates de l’IT est bel et bien devenue un produit
Je pense que, dans l’industrie tech, ces tâches augmentent plutôt qu’elles ne diminuent : il y a aujourd’hui X tâches ingrates, une nouvelle technologie Z arrive et réduit X à 0,1X, mais en même temps Z rend possibles de nouvelles façons de travailler et crée en sous-produit d’autres tâches ingrates. Le volume devient alors Y, et Y reste à peu près proche de X
Si le progrès technologique s’était arrêté dans les années 2000, les tâches ingrates issues des années 90 auraient aujourd’hui presque disparu, mais les nouvelles technologies apportent à la fois de l’automatisation et de nouvelles corvées
Un exemple récent, ce sont les outils d’IA. Il existe des outils pour générer du son, des images, de la vidéo et du texte, mais pour créer un produit ou une expérience différenciés, il faut encore faire le travail ingrat qui consiste à combiner des outils comme ChatGPT ou Stable Diffusion
Plus on transforme les choses en produits, plus les problèmes remontent à un niveau d’abstraction supérieur, et les ingénieurs spécialisés qu’on recrute se déplacent eux aussi vers le haut de la stack
Parmi les produits de startups récemment passés en SaaS, une grande proportion semble ne pas encore faire réellement ce qu’on attend d’eux. Le modèle consiste à faire payer le client pour utiliser le service, puis à collecter ses cas d’usage comme éléments à implémenter et à les transformer en produit pour d’autres clients ; cela allonge les délais et fait aussi fuiter la propriété intellectuelle
La mise en templates de SQL est un sujet que les dirigeants comprennent toujours de travers. SQL a survécu étonnamment longtemps dans l’industrie, et il est en fait plutôt efficace. 99 % des wrappers ou DSL qu’on ajoute par-dessus le rendent bien pire, et dès qu’une tâche sort un peu de l’ordinaire, il faut finalement redescendre à SQL. Au lieu de recruter un expert SQL, on se retrouve à devoir former un expert d’un wrapper DSL SQL SaaS X qui n’existe même pas vraiment
Le problème fondamental est peut-être que ces produits sont conçus pour apparaître aux acheteurs qui ne travaillent pas dans le domaine comme des appareils électroménagers qu’il suffirait d’acheter et de brancher pour résoudre le problème
Beaucoup de produits ne résolvent pas réellement le problème ; ils donnent seulement l’impression de le résoudre parce que d’autres les achètent. Et il faut mentir en disant que l’implémentation a réussi pour pouvoir obtenir une promotion. Des choses comme le publipostage sont vraiment des problèmes déjà résolus, comme une bouilloire ; pour ce genre de problème, il suffit d’essayer soi-même et de le régler
Le problème plus important, c’est que mon employeur a acheté Workday en pensant que c’était une sorte de bouilloire, mais il n’a pas pu corriger le fait que notre structure organisationnelle était tellement catastrophique qu’elle ne pouvait même pas être modélisée
Cette année, j’ai compris pour la première fois que, dans une grande entreprise, une structure organisationnelle suffisamment mauvaise est une forme de dette technique. On finit par faire toutes sortes de choses étranges pour déterminer qui travaille sous les ordres de qui, et ce que tel utilisateur peut voir dans telle base de données
Par rapport à 1994 ou 2004, à quel point est-il devenu plus simple aujourd’hui de gérer une entreprise, de créer un site web, de planifier un voyage ou de payer des factures ?
J’ai parfois l’impression que les générations précédentes vivaient à un rythme plus lent et avaient donc une vie plus pleine. Aujourd’hui, le temps passe beaucoup trop vite et le stress est élevé
Récemment, dans une banque, j’ai vu au moins trois personnes de plus de 60 ans perdues face à des démarches simples, demandant de l’aide au personnel. Cela aurait dû être facile à faire via la banque en ligne, mais à cause de cas d’exception, le système ne le prenait pas en charge ; il a finalement fallu prendre rendez-vous, et le premier créneau disponible était dans 3 ou 4 mois
L’une de ces personnes devait retirer de l’argent d’un compte bloqué pour acheter du bois de chauffage et chauffer sa maison, mais l’employé de banque lui a simplement dit d’attendre trois mois
Il y a deux ans, mon père n’a pas trouvé de moyen simple d’appeler chez lui depuis la Sicile. Dans les années 1970, il lui aurait suffi d’entrer dans un bar à proximité et de mettre quelques pièces
Autrefois, une personne ordinaire pouvait réparer elle-même une lampe, une voiture, le chauffage ou une porte qui n’était pas automatique ; aujourd’hui, il faut faire appel à un spécialiste
Les tentatives de marchandiser entièrement le travail technique sont une mauvaise idée, et j’espère qu’elles continueront d’échouer
Cela dit, même si j’ai lu The Phoenix Project deux fois et que je déteste la majeure partie de Scrum, je ne pense pas que ce livre défende cela
Ce que j’en ai surtout retenu, c’est qu’il faut disposer d’un système clair pour exécuter et gérer les tâches répétables, automatiser là où c’est possible, réduire le travail en cours afin que les gens ne soient pas coincés dans une multitude de tâches, partager largement l’information et permettre à plusieurs membres d’une équipe de faire le même travail, vérifier qu’on fait bien ce dont l’entreprise a réellement besoin, et réduire le bruit ainsi que le travail non planifié pour que les employés puissent se consacrer à des tâches à forte valeur ajoutée, qu’ils apprécient, plutôt que de patauger dans un marécage désordonné
Le propos de The Phoenix Project n’est pas de transformer les gens en automates interchangeables, mais de créer un système qui leur donne l’espace et le temps nécessaires pour faire le travail réellement précieux qui ne peut être ni automatisé ni systématisé
Ayant dirigé une usine et ayant aussi été développeur, je vois les deux côtés : transformer les développeurs en ouvriers de production n’a aucun sens, mais les tâches qui ressemblent au travail d’usine, avec des opérations connues et des étapes répétables, doivent être traitées de manière similaire
s/manufacturing/IT/g, puis une mise à jour avec des références modernesÇa ne veut pas dire que je n’aime pas le livre. Je l’ai lu à moitié et j’ai essayé de le faire lire à chaque équipe pour les amener à penser davantage en termes de systèmes. Mais je ne dirais pas qu’il est beaucoup plus profond ou perspicace que The Goal
Je me suis moqué du style, mais il valait vraiment la peine d’être lu. On ne peut pas mettre sur le compte de la pensée façon Phoenix Project toutes les erreurs que les gens commettent avec les tâches connues ou les étapes répétables
Cela dit, en programmation, il est rare d’exécuter des tâches connues sous forme d’étapes répétées. Quand cela arrive, c’est souvent parce qu’on a commis une erreur tactique dans la gestion des parties prenantes, au point de ne plus avoir le temps d’automatiser
Une lecture réfléchie mène à une conclusion comme celle du dernier paragraphe, mais je sais avec certitude que la plupart des managers que je rencontre ne comprennent pas la différence entre production de widgets et conception de systèmes
L’apprentissage continu, l’automatisation et l’instrumentation sont les outils qui rendent possibles les points 1 à 5 ci-dessus
Je n’ai pas reçu de The Phoenix Project le message « travaillez plus dur pour faire plus de choses plus vite »
https://scrumguides.org/scrum-guide.html
Ce qui est généralement horrible, ce sont toutes les choses disparates que les gens empilent par-dessus en appelant ça Scrum. La meilleure façon de s’opposer au mauvais Scrum n’était pas de se battre, mais de faire semblant d’être un puriste fidèle à la doctrine réelle. On a moins l’air d’un rebelle, et il est plus facile d’avoir de l’influence
Le titre m’a laissé perplexe. « commodify » ne veut-il pas dire « rendre vendable », autrement dit commercialiser ? La tech n’a-t-elle pas déjà rapporté des milliards de dollars ?
Ce dont parle l’auteur semble plutôt être la commoditization, c’est-à-dire le fait de transformer le travail technique en tâche générique que n’importe quel employé remplaçable peut accomplir
D’après https://en.wikipedia.org/wiki/Commoditization, on peut résumer ainsi : la commoditization, c’est quand quelque chose de propriétaire devient un bien générique, tandis que la commodification, c’est quand quelque chose qui n’était pas vendable le devient
Est-ce que je pinaille trop ? Je pensais que les deux termes avaient des sens différents
Modification : en regardant le Wiktionary, https://en.wiktionary.org/wiki/commodification indique qu’ils sont parfois utilisés de manière interchangeable. C’est sans doute juste une confusion courante
https://www.merriam-webster.com/dictionary/commodify
Cela signifie « transformer en marchandise quelque chose doté d’une valeur intrinsèque, comme une œuvre d’art » ; commodify relève donc plutôt de la commoditization
Le pétrole est une commodité parce qu’il existe de nombreux producteurs et qu’ils fabriquent tous la même chose, si bien que peu importe auprès de qui on l’achète
Dans l’analogie avec McDonald’s, le développeur n’est pas l’adolescent qui travaille devant la machine, mais l’ingénieur qui a conçu la machine. Dans cette analogie, c’est l’ordinateur qui est l’adolescent.
Programmer n’est pas du travail, c’est du méta-travail. Une fois qu’on a établi une liste d’instructions, l’ordinateur exécute ce travail en continu, 24 h/24, et moi je pars rédiger une nouvelle liste d’instructions pour autre chose.
Si l’on écrit deux fois la même liste d’instructions, c’est qu’en gros on s’y prend mal. C’est pour cela qu’on fait toujours quelque chose de nouveau ; et comme on ne fait pas deux fois la même chose, il est difficile de savoir combien de temps cela prendra.
L’IT n’est pas une usine, c’est le travail qui consiste à fabriquer des usines.
Je pense que beaucoup de conflits entre développeurs et managers viennent du fait que le mot « manager » est trop fourre-tout. Un manager chez McDonald’s supervise le fait que les employés suivent le processus qui produit le produit. Il est clair qu’ils suivent ou non le processus, le processus est supposé valable, et il est clair aussi si le résultat n’est pas produit.
À l’inverse, un programmeur est embauché pour développer le processus que la machine suivra. La personne qui gère cet employé peut elle aussi avoir un processus que le programmeur doit suivre, et il peut être clair qu’il le suit ou non ; mais il est incertain que ce processus soit valable, qu’une action donnée mène au résultat prévu, ou même que le résultat lui-même soit clair.
Pourtant, on appelle les deux rôles « manager ».
Dans cette analogie de la machine, le programmeur n’est pas quelqu’un qui manage des personnes, mais un autre type de manager qui dirige des machines. Simplement, ces machines sont ensuite lâchées dans le monde, et le programmeur ne les surveille pas en permanence.
Bien sûr, comme le disent d’autres commentaires, il est possible que ce concept soit une absurdité totale. Mais même si, dans quelques années, je me rends compte que c’était une idée stupide, il vaut mieux avoir quelqu’un avec qui partager la honte que d’être gêné tout seul.
Il y a une dizaine d’années, quelques amis ingénieurs en mécanique ont été surpris d’apprendre que j’étudiais le développement logiciel.
Ils disaient des choses comme : « Il reste encore beaucoup à faire ? Les systèmes existants ne permettent-ils pas déjà de faire tout ce dont on a besoin ? »
Le malentendu consiste à croire que créer des systèmes pour résoudre de nouveaux problèmes est facile et déjà commoditisé, au point qu’il n’y aurait plus besoin d’écrire du code.
En réalité, construire un logiciel est rarement aussi simple que de configurer une UI. Il faut du texte pour exprimer les règles logiques et les flux, il faut du contrôle de version pour suivre et annuler les changements du système, et au bout du compte il faut des programmeurs.
Le codage ne disparaît pas ; seul le niveau d’abstraction monte.
Le secteur tech essaie depuis longtemps de commoditiser les développeurs, et je pense que COBOL comme Java s’inscrivaient dans ce mouvement.
Mais quelle que soit l’abstraction choisie, certaines propriétés essentielles réapparaissent. Même lorsque les exigences semblent simples et qu’il existe des frameworks de haut niveau, une bonne partie de nos logiciels ne fonctionne toujours pas correctement.
Comme le dit l’auteur, la vraie solution, ce sont des développeurs compétents et consciencieux. On peut bâtir une carrière là-dessus.
Quand on travaille longtemps dans un même domaine, les motifs se répètent de manière similaire, mais chaque entreprise a des exigences métier légèrement différentes. À chaque couche de la stack, ces différences s’amplifient, et au total il y a une quantité énorme de travail non commoditisé et sur mesure.
C’est pour cela que deux produits ne sont jamais exactement identiques, et qu’il n’existe pas une unique méga-entreprise mondiale qui produirait tout.
J’ai vu d’innombrables fois des développeurs s’enthousiasmer dès qu’une occasion de s’auto-commoditiser se présentait, sous la forme d’un découpage tayloriste d’eux-mêmes.
Le secteur médical est le contre-exemple que j’utilise quand les discussions sur la commoditisation automatique surgissent. Il y a deux attraits émotionnels. Les patients n’aiment pas être transférés d’un médecin à l’autre. Ils comprennent que la commoditisation s’accompagne d’un certain degré de spécialisation accrue, et que chaque passage de relais supplémentaire ajoute un point de défaillance.
Le second attrait est qu’on peut présenter son statut et sa façon de travailler comme relevant d’un statut plus élevé. Si l’on met le premier argument en avant et que le second reste lisible en sous-texte, cela fonctionne généralement bien. Les travailleurs conservent des compétences plus généralistes et s’appuient davantage sur la consultation mutuelle que sur les passages de relais.
La chaîne de montage est une spécialisation séquencée ; il suffit de regarder les erreurs de transmission liées aux horaires des internes en médecine.
Exploitation, innovation, maintenance. Choisissez-en trois parmi les trois.
Il est préférable que ce soit la même équipe qui s’en charge, ou des équipes très proches les unes des autres.
Idéalement, chaque membre de l’équipe devrait exercer les trois fonctions à des degrés divers. C’est de là que vient l’inspiration pour s’améliorer.
On peut aussi répartir ces trois fonctions entre trois groupes et trois couches de management, mais le résultat est généralement médiocre et les gens deviennent malheureux. En particulier, ceux qui se retrouvent enfermés dans l’équipe de maintenance accomplissent un travail essentiel sans recevoir de reconnaissance.
On peut rendre une équipe responsable des trois fonctions, mais on finit souvent par recruter un manager suradapté à une seule d’entre elles. Comme par hasard, cette fonction est celle qui mènera à une meilleure rémunération au trimestre suivant.
Il est difficile de défendre simultanément, au sein d’une même culture, l’excellence opérationnelle, une maintenance consciencieuse et du temps pour réfléchir en profondeur. C’est normal que ce soit difficile.
Pour le rôle business intelligence/analyste, le secteur essaie de remplacer les personnes qui écrivent du SQL par des personnes qui utilisent des outils comme Tableau.
L’idée est du genre : « connectez-vous à n’importe quel entrepôt de données et des profils non techniques pourront le faire par glisser-déposer ».
Il y a plusieurs problèmes. D’abord, on oublie que la production n’augmente que linéairement, ce qui oblige à recruter davantage de main-d’œuvre peu coûteuse. Comme tout passe par une UI, quelqu’un doit tourner la manivelle à la main.
Ensuite, on se retrouve toujours avec du code de transformation de logique métier très complexe et mal organisé, mais cette fois enfoui dans l’UI. Les seules personnes qui savent ce que fait cette logique sont les PM ou les équipes métier.
L’organisation d’ingénierie fournit des jeux de données de haute qualité, testés et assez bruts, pour répondre aux questions métier. La partie difficile consistait à résoudre le problème consistant à obtenir des résultats métier, parfois de façon étrange, à partir des données sources.
Désormais, cette solution est stockée dans un workbook Tableau et ne peut pas servir d’entrée ailleurs. Il faut la copier-coller dans l’UI vers un nouveau workbook Tableau.
Comme on a acheté le service cloud Tableau, l’équipe BI peut rendre les extractions SQL plus strictes et les maintenir. Tableau semble vouloir capter une partie du business de Databricks, mais ce sont désormais des équipes non ingénierie qui font ce travail. Je ne sais pas si ça se passera bien.
Par exemple, il y a la question classique : « de quel pays viennent nos utilisateurs ? ». Parle-t-on du pays indiqué dans le formulaire d’inscription, du pays depuis lequel ils accèdent actuellement au service, du pays du moyen de paiement, du pays de naissance, du pays de citoyenneté, du pays de résidence actuelle, de l’adresse de livraison ou de l’adresse de facturation ? Ce sont toutes des choses différentes.
Si le jeu de données est assez grand, chacune donnera une réponse différente. Dans le domaine de la « fintech globale », ce genre de cas étrange deviendra la norme.
L’utilisateur Tableau typique, peu payé, risque de trouver le code pays visible, de faire un count, puis de le déclarer comme vérité.
Un utilisateur Tableau un peu plus malin demandera à un ingénieur d’écrire le SQL.
Il faut quelqu’un qui connaisse les jeux de données et les systèmes sources pour répondre au business par des questions, et imposer les bonnes questions et le bon contexte.
Les outils du type Tableau sont bons pour remplacer le « travail technique » consistant à coller chaque jour la même requête SQL dans pgAdmin puis à envoyer un CSV par e-mail, mais ils ne rendent pas des opérateurs peu qualifiés centrés sur l’UI meilleurs dans leur réflexion.
La mise à l’échelle linéaire de la production par rapport au coût peut être modélisée dans un tableur, puis répercutée ou facturée au client. Tout le monde dans la couche business est à l’aise avec cette dynamique.
À l’inverse, une situation où un expert dédié peut produire 1000 fois plus avec peu d’effort, sans qu’on sache si cela prendra une journée ou une semaine, rend tout le monde incertain et inquiète les dirigeants. C’est difficile à vendre si tout le monde veut une médiocrité confortable.
Le point 2, ironiquement, rend nécessaires davantage d’experts, simplement d’un autre type, puisqu’il faut maintenir toute cette logique.
Au final, cela fonctionnera comme un programme de création d’emplois et coûtera plus cher, mais distribuera la valeur proportionnellement à des fiefs politiquement influents, et c’est pour cela que ça réussira.
D’abord, on licencie tous les gens du backend au motif qu’ils ne comprennent pas le business, et on fait de Tableau le nouveau backend. On ignore le fait que les gens du backend absorbaient et affinaient les exigences métier.
Ensuite, quand les équipes business se retrouvent empêtrées dans la toile d’araignée chaotique qu’elles ont créée, elles appellent des consultants Tableau, qui siphonnent de l’argent sans rien produire de valeur.
Je viens du génie civil structurel, et le logiciel me semble plus proche de l’urbanisme que des autres disciplines d’ingénierie.
C’est trop vaste. Il n’est pas surprenant de voir apparaître, avec le temps, de plus en plus de postes décrivant des types de tâches spécifiques, comme ingénieur backend, frontend, firmware, machine learning, data scientist, analyste sécurité ou développeur kernel.
À mesure que les standards évolueront, il se peut qu’à un moment donné il faille des certifications très spécifiques pour occuper ce genre de poste. Cela pourrait prendre une autre forme, mais on voit clairement l’effet de cristallisation.
Considérer le logiciel comme une usine est aussi possible, et peut être utile. Mais tout ne rentre pas dans cette analogie. Par exemple quand on pense à l’intégration produit, ou lorsqu’il s’agit d’un service plutôt que d’une app.
Une usine implique que quelque chose est fabriqué, alors que dans de nombreux cas le logiciel n’est pas le résultat final, mais le moyen qui rend quelque chose possible.
Dans le logiciel, la plupart des tâches ont été automatisées de façon asymptotique. C’est pourquoi on oublie qu’elles ont autrefois été du travail.
Il suffit de penser à la simple copie de fichiers. C’est, pour ainsi dire, un « copiste automatique ».
La copie a été automatisée au point que l’immense quantité de copies effectuées par nos systèmes est devenue invisible, et elle a disparu comme facteur de différenciation économique.
En plus, elle est utile au niveau méta : le programme de copie lui-même se copie facilement avec le même algorithme.
Le point essentiel est que l’écriture de logiciel, comme les mathématiques, passe toujours son temps à la frontière entre le connu et l’inconnu. Car tous les domaines entièrement connus et caractérisés sont automatisés d’une manière qui résout le problème pour tout le monde tout en brûlant le terrain économique de cette activité.
Le travail logiciel comporte toujours, dans n’importe quel domaine, une part d’exploration — donc de recherche — qui consiste à s’aventurer dans l’inconnu pour y trouver de la richesse. Que ce nouveau territoire soit glorieux ou tragiquement banal.
Les domaines qu’un manager sans expertise logicielle peut automatiser sont comme des arbres fruitiers domestiqués pour qu’on puisse en cueillir facilement les fruits. Sauf que ces arbres n’ont plus de fruits.
Si la définition du problème de ce manager ne remonte pas vers des domaines difficiles à automatiser, qui exigent à nouveau cette créativité et cette expertise agaçantes, alors il ne fait plus un travail différenciant ni précieux.