- Les utilisateurs accordent plus d’importance au fonctionnement du produit qu’aux propriétés intrinsèques du code lui-même, mais un mauvais code a des effets indirects directs sur les performances, les bugs et la vitesse de développement
- Dire que « les utilisateurs ne se soucient ni de la stack technique ni des tests » est superficiellement vrai, mais plus la qualité du code est faible, plus il devient difficile et lent de corriger les bugs et d’ajouter des fonctionnalités
- Comme dans les analogies de l’inspection d’un pont, d’un pilote ivre ou des fondations instables d’un bâtiment, même si l’utilisateur ne voit pas le processus lui-même, le résultat a un impact sur la sécurité et la fiabilité
- Si ce lieu commun est si populaire, c’est peut-être parce qu’un mécanisme de défense de l’ego pousse à dévaloriser ce que l’on ne maîtrise pas bien soi-même
- Le travail logiciel sérieux est un mélange de préoccupations et de points de vue variés, et chacun contribue à la réussite ou à l’échec ; il ne faut donc pas prendre à la légère la qualité du code
Un cliché récurrent et ses limites
- Dans l’industrie du logiciel, on entend sans cesse des phrases du type
- « Le client ne se soucie pas des tests, il veut juste que le produit fonctionne »
- « Les utilisateurs ne se soucient pas de la stack technique »
- « L’élégance d’ingénierie n’est pas la même chose que la valeur marché »
- « Les utilisateurs ne se soucient pas de savoir si c’est l’IA ou un humain qui l’a écrit, ni du framework utilisé ; ils veulent juste que le produit fonctionne »
- Toutes ces formules sont des variantes d’un même thème : « le client ne s’en soucie pas »
- Elles adoptent une posture comme si un pragmatique chevronné venait révéler la dure vérité du monde à des idéalistes ou à des gens à courte vue
- Mais tout cela, c’est du baratin (horseshit), et
appliquer la même logique à d’autres domaines en révèle aussitôt les failles- Les usagers de la route ne se soucient pas de savoir si un pont a passé son inspection finale ; ils veulent juste qu’il supporte leur voiture
- Les passagers ne se soucient pas de savoir si le pilote est ivre ; ils veulent juste que l’avion arrive à l’heure
- Les employés de bureau ne se soucient pas de savoir si les fondations d’un immeuble de grande hauteur sont stables ; ils veulent juste gagner de l’argent
- Ces analogies paraissent justes en surface, mais elles ignorent des effets en aval (downstream effects) pourtant évidents
Les effets en aval qu’on ignore
- Il est vrai que les clients ne s’intéressent pas aux propriétés intrinsèques du code informatique, mais la qualité du code influe sur les performances, la présence de bugs, le temps nécessaire pour corriger les bugs et le temps nécessaire pour ajouter des fonctionnalités
- Plus le code est mauvais, plus il devient difficile et lent de résoudre ces problèmes
- Des entreprises comme AirBnB, OpenAI ou Meta peuvent balayer ces inquiétudes grâce à une énorme emprise sur le marché, un soutien massif du capital-risque et une légalité discutable
mais, si vous n’êtes pas ce type d’entreprise, il est beaucoup plus difficile de masquer les problèmes de la même manière
La persistance de la « sagesse populaire » et les multiples préoccupations du logiciel
-
La longévité tenace des idées reçues (The Persistence of Folk Wisdom)
- L’idée selon laquelle seuls les effets de premier ordre comptent est devenue une forme très populaire de sagesse populaire dans le logiciel
- Les gens ont tendance à minimiser ou à rabaisser ce dans quoi ils ne sont pas très bons
- Lorsqu’on se perçoit comme incapable de produire du bon code, on a facilement tendance à considérer non seulement que le bon code n’a pas d’importance, mais aussi que ceux qui savent en produire sont en réalité le problème
- Dans cette vision, ceux qui retardent une sortie pour des choses dont le client ne se soucie pas passent pour les vrais fautifs
- Cette attitude fonctionne comme un mécanisme de défense de l’ego (ego defence mechanism) qui évite d’affronter ses propres faiblesses et reporte la responsabilité sur les autres
-
Nous vivons en société (We Live in a Society)
- Le travail logiciel sérieux est un mélange de préoccupations et de points de vue différents
- De la tech sales à la tech stack, de l’expérience utilisateur (UX) aux identifiants uniques (unique identifiers), de nombreux éléments entrent dans un effort logiciel
- Tous ces éléments contribuent à la réussite ou à l’échec
1 commentaires
Avis sur Lobste.rs
Ce genre de phrase peut être bonne ou mauvaise, autant dans la manière de la transmettre que de la lire
Par exemple, dire « le client ne se soucie absolument pas des tests ; il se soucie de savoir si le produit fonctionne » peut se lire non pas comme « expédiez des bugs », mais comme une invitation à se concentrer sur le fait que le produit fonctionne réellement plutôt que sur une idéologie des tests particulière
Les tests ne sont qu’un des moyens de faire fonctionner le code ; ainsi, si la couverture de tests est élevée et que tout passe mais que le produit ne marche pas, c’est un échec ; à l’inverse, si le produit fonctionne bien grâce à d’autres approches que les tests, c’est acceptable, et si on détecte bien les bugs sans suivre une doctrine formelle, cela peut aussi être acceptable
Du point de vue des utilisateurs et du business, « l’absence du produit/de la fonctionnalité » peut aussi être un bug ; corriger des bugs existants et livrer des fonctionnalités ne sont donc pas toujours des activités proprement séparées
Cela dit, j’ai aussi déjà vu ce genre de phrase utilisée pour dire en pratique « bâclez le travail et livrez de la merde »
Je rejette totalement l’idée qu’une programmation médiocre puisse être « pragmatique », même à l’échelle de plusieurs mois
Dans une base de code mal conçue et insuffisamment testée, développer de nouvelles fonctionnalités est lent et coûteux
Les développeurs devraient être conscients de là où leur temps crée de la valeur, et idéalement la direction devrait aussi comprendre pourquoi ils travaillent sur ces sujets
Quand un manque de compréhension se combine à une mauvaise structure d’incitations, on finit effectivement par « bâcler le travail et livrer de la merde »
Honnêtement, ceux qui disent ce genre de chose donnent souvent l’impression de ne pas beaucoup se soucier non plus des utilisateurs
Pour que les utilisateurs reçoivent un produit qui fonctionne, il faut intégrer dans le processus de développement des mécanismes qui augmentent cette probabilité, comme je l’ai déjà dit dans un commentaire il y a quelques jours
Cet état d’esprit apparaît souvent dans des situations où les utilisateurs n’ont aucun vrai moyen de faire des retours sur le produit, et où il n’y a pas non plus de véritables indicateurs d’usage
Il existe aussi de nombreux scénarios d’échec qui affectent les utilisateurs même s’ils ne les voient pas immédiatement ou ne s’en soucient pas sur le moment
La sécurité, par exemple : un utilisateur peut ne pas se préoccuper du fait que ce n’est « pas sûr » tant que ses données n’apparaissent pas dans une fuite en ligne ; de même, il peut ne pas percevoir les performances comme un problème tant qu’il ne sait pas qu’elles pourraient être bien meilleures
Il est difficile d’obtenir de bons résultats en optimisant un seul élément d’un processus d’amélioration, mais pour faire avancer la discussion, on est souvent obligé de procéder ainsi
Il est donc utile d’ajuster le cadre du débat en alignant les circuits de retour pour identifier où se situe réellement le problème visible
Je vois ce type d’article comme une tentative de faire réfléchir à des éléments qui influencent la réussite d’un projet logiciel tout en pouvant sembler mutuellement exclusifs
Il y a de la valeur à mettre en mots et à défendre des choses que seuls les gens dotés d’une intuition technique perçoivent ; mais beaucoup de techniciens semblent mal équilibrer ce travail invisible ou peinent à le défendre efficacement, et c’est aussi un point que je continue à travailler
Se soucier de l’interne est important, et en pratique cela profite aussi aux utilisateurs
J’aime bien cette perspective
Je ne veux pas basculer dans l’extrême inverse, celui de la sur-ingénierie, mais j’aimerais qu’on sorte de cette mentalité du « avancer vite et tout casser »
D’après mon expérience, c’est presque une épidémie dans le monde du développement web
J’aimerais que l’afflux de logiciels de mauvaise qualité rendu possible par les LLM pousse au contraire les utilisateurs à récompenser les logiciels fiables
Je deviens de plus en plus un développeur grug brain, donc je ne sais pas si c’est un ressenti largement partagé, mais je suis fatigué du « ajoutons juste une fonctionnalité de plus »
On fait souvent l’erreur de mesurer le coût d’un logiciel uniquement à sa date de sortie, en excluant presque entièrement les coûts de maintenance sur toute sa durée de vie
On dit « ce n’est pas compliqué, ça prendra moins d’une semaine ! », mais on ne parle pas du temps qu’il faudra ensuite consacrer chaque année — 2 à 4 semaines — à la maintenance, aux corrections, aux extensions, aux mises à jour, à l’intégration et à la documentation
Je dis souvent quelque chose dans le même esprit
« L’utilisateur final ne se soucie pas de savoir si le logiciel a une couverture de tests de 100 %, ni s’il est écrit à 100 % en assembleur non documenté avec des labels comme
lbl0. Il se soucie de l’exactitude, des performances et de l’expérience utilisateur »Mais l’ingénierie logicielle permet justement d’atteindre plus facilement ces objectifs et de maintenir la qualité à un bon niveau
Le problème, c’est que cette voie aussi peut dériver vers le cargo cult et la sur-ingénierie, et j’en suis moi-même clairement coupable
Malgré tout, il faut au final livrer une vraie valeur aux utilisateurs
Comme chez Boeing et Airbus, il existe des résultats optimaux démontrables
La question n’est pas de savoir pourquoi les avions des deux entreprises se ressemblent autant, ni qui a conçu quoi en premier ou qui a copié qui
Personne n’a copié : les meilleurs ingénieurs du monde, répartis dans des équipes différentes, conçoivent sous les mêmes contraintes, et tout design qui s’en écarte devient par définition inférieur
Il faut se situer sur la frontière de Pareto, sinon on se fait éliminer
Dans notre domaine aussi, il existe quelque part un optimum ; la question est de savoir si l’on dispose des outils, du budget et des bonnes personnes pour l’atteindre, et s’il y a assez d’utilisateurs pour pouvoir déterminer si on l’a effectivement atteint ou non