- Le rôle fondamental d’un logiciel consiste à bien comprendre le problème qu’il doit résoudre et à reconnaître ses limites
- Un bon logiciel ne cherche pas à tout faire : il ne traite que ce qui doit être amélioré et ne s’écarte pas de son objectif
- L’article imagine un cas où la commande
ls serait remplacée par des fonctions d’IA, et tourne en dérision la tendance des outils existants à s’étendre inutilement
- En citant les principes présentés dans « Getting Real » et « Rework » de 37Signals, il souligne qu’il faut faire des contraintes un avantage et savoir refuser les demandes de fonctionnalités inutiles
- Même en pleine vague IA, il rappelle que la stabilité des standards existants et une définition claire du problème ont plus de valeur qu’une nouvelle mode
Le rôle et les limites du logiciel
- Le texte s’ouvre sur une scène imaginaire : après la mise à jour d’une distribution Linux, la commande
ls devient une intelligence de répertoire alimentée par l’IA
- La nouvelle commande
als prédit l’intention de l’utilisateur, classe les fichiers par ordre de priorité, et affiche un message indiquant que l’ancienne commande ls ne sera plus prise en charge dans 30 jours
- Cette scène est une satire de la surenchère fonctionnelle et de l’innovation inutile
- « Heureusement, cela n’arrive pas en réalité » : l’auteur insiste sur le fait qu’un bon logiciel sait quand il doit s’arrêter
Les principes essentiels d’un bon logiciel
- Un bon logiciel sait à quoi il sert ; il ne cherche pas à tout faire, et distingue ce qu’il faut améliorer du moment où il faut s’arrêter
- La « pensée maximaliste » humaine a tendance à vouloir tout rendre plus grand et plus complexe
- Mais un logiciel doit définir clairement son rôle et sa place ; si une nouvelle idée ne correspond pas à la vision existante, il faut la séparer dans un projet distinct
La philosophie produit de 37Signals
- « Rework » et « Getting Real », écrits par les fondateurs de Basecamp, livrent des enseignements importants pour la conception produit
- Les contraintes sont des avantages (Constraints are advantages) : une petite équipe, un budget limité et un périmètre restreint conduisent à de meilleures décisions
- Ignorer les demandes de fonctionnalités (Ignore feature requests) : plutôt que d’implémenter telles quelles les fonctionnalités demandées par les utilisateurs, il faut comprendre le problème de fond
- Lancer tôt, lancer souvent (Ship early, ship often) : un produit imparfait mais qui fonctionne réellement a plus de valeur qu’un produit parfait qui n’est jamais lancé
- Conception centrée sur l’épicentre (Epicenter design) : il faut concevoir d’abord l’interface et les interactions essentielles, plutôt que la navigation ou les éléments périphériques
- Dire « non » par défaut (Say no by default) : chaque nouvelle fonctionnalité entraîne des coûts cachés en complexité, maintenance et gestion des cas particuliers
- Construire ce dont on a soi-même besoin (Scratch your own itch) : un produit qui résout un problème dont on a réellement besoin permet de meilleures décisions
La valeur de la continuité plus que du changement
- On observe récemment une tendance où plusieurs produits réorganisent leur nom et leurs fonctionnalités autour de l’IA
- MinIO → AIStor
- Oracle Database → Oracle AI Database
- Tout n’a pas besoin de changer de manière spectaculaire
- Devenir un standard de facto dans un domaine précis a davantage de valeur
1 commentaires
Avis sur Hacker News
En voyant le conseil « ignorez les demandes de fonctionnalités », cela m’a rappelé le cas de Blizzard et World of Warcraft Classic
Pendant des années, les joueurs ont demandé une version classique, mais Blizzard a refusé en disant : « vous ne voulez pas vraiment ça »
Ils ont finalement lancé WoW Classic, qui a connu un succès retentissant
Plus tard, l’équipe de développement a reconnu que « les joueurs savaient vraiment ce qu’ils voulaient »
Autrement dit, au lieu d’ignorer systématiquement les demandes de fonctionnalités, il faut admettre que les utilisateurs peuvent parfois avoir parfaitement raison
À l’inverse, avec des utilisateurs impolis ou égocentriques, la conversation devient épuisante et on finit par ne plus répondre
La leçon, au fond, c’est qu’il faut formuler ses demandes avec courtoisie
Ensuite, il faut juger si la demande est valable et réfléchir à la manière de l’implémenter
Le vrai problème était un « jeu qui avait perdu sa sensation d’origine », et si cela avait été bien compris, on aurait pu y répondre autrement qu’avec une version Classic
WoW Classic était l’expression d’un désir superficiel de retrouver une nostalgie passée, mais en dessous se cachait une méfiance envers une orientation produit jugée peu fiable
Dans un monde idéal, on pourrait créer une forme parfaite mêlant le meilleur des deux versions, mais dans la réalité, les désaccords ne feraient qu’ajouter de la confusion
En ajoutant, à la demande des joueurs, des instances non-PVP, le jeu a perdu sa tension et est devenu fade
Dans ce cas, les développeurs comprenaient mieux le problème que les utilisateurs
Il devrait y avoir davantage de logiciels achevés qui cessent d’ajouter des fonctionnalités
Il faut avoir le courage de dire : « c’est suffisant comme ça »
Il existe beaucoup d’exemples, comme Evernote ou Dropbox, qui étaient parfaits à une époque avant de devenir confus à cause de la surcharge fonctionnelle
On les vendait dans une boîte, et quand une nouvelle version sortait, il fallait acheter une nouvelle boîte
C’était l’époque d’avant les webapps mises à jour en permanence
Bien souvent, plus on les met à jour, plus ils empirent
Les produits qui s’améliorent réellement sont très rares
Au final, il a recréé le problème qu’il cherchait initialement à résoudre
Mais avec le temps, elle n’est plus devenue compatible avec les nouvelles versions d’iOS et a fini par être inutilisable
J’y ai vu à la fois la beauté de l’achèvement et la cruauté de l’évolution technique
Quand je suis passé de l’infra au poste de développeur Java en 2020, beaucoup de bibliothèques majeures étaient en mode maintenance, et je me suis demandé : « Java est-il mort ? »
Plus tard, j’ai compris que c’était en fait un état de maturité fonctionnelle
Elles étaient stables, avec d’innombrables cas limites déjà résolus
Le problème, c’est que les gens ne veulent pas vraiment cette stabilité et préfèrent toujours la nouveauté
Résultat, on recrée sans cesse les mêmes frameworks en changeant seulement de langage
Ils préfèrent donc des projets encore en développement actif
Certaines entreprises, elles, ne peuvent utiliser que des logiciels continuellement mis à jour à cause des exigences de conformité
Je plaisantais en disant : « elle est juste terminée, il n’y a plus rien à améliorer », mais j’ai quand même fini par migrer
J’aime Sublime Text pour sa simplicité et sa rapidité
Il n’ajoute ni IA ni fonctionnalités complexes, et reste concentré sur un seul objectif
Un bon logiciel n’est pas forcément un logiciel qui rapporte de l’argent
Mais pour en gagner, il faut des fonctionnalités que les gens utilisent réellement
Comme chaque utilisateur se sert de 20 % de fonctionnalités différentes, il faut aussi tenir compte de cette diversité
Je pensais que Notepad.exe était un exemple emblématique de logiciel achevé,
mais j’ai été surpris de voir qu’il faut des manipulations dignes d’un piratage pour changer les associations de fichiers sous Windows 11
Si l’on en croit le blog Windows Insider et cet avis de sécurité,
le problème vient justement de mises à jour qui ne savent jamais s’arrêter
Je reconnais la beauté des logiciels achevés, mais aujourd’hui la plupart sont dans un état de « bêta perpétuelle »
La connexion permanente à Internet a créé un modèle où « on peut toujours mettre à jour plus tard »,
sans séparation entre correction de bugs et ajout de fonctionnalités non désirées
Avec des services web comme YouTube, il est même impossible de choisir sa version
L’ajout de la fonction Canvas a notamment ébranlé sa philosophie de simplicité d’origine
Si c’était open source, je l’aurais peut-être forké à ce moment-là
Signal est gratuit, open source et centré sur la vie privée, donc il a peu de fonctionnalités
Mais c’est justement ce qui me plaît
WhatsApp, lui, ne cesse d’ajouter des fonctions inutiles
À une époque, je ne comprenais pas l’importance de l’« evergreen » évoqué dans les livres de 37signals, en particulier la vitesse
Mais en voyant les applications devenir de plus en plus lentes avec le temps, j’ai réalisé à quel point les logiciels rapides ont de la valeur
Cela me rappelle la phrase « les écrivains aiment les enclaves résidentielles » dans REAMDE de Neal Stephenson
De la même manière que les écrivains créent sans cesse du travail pour préserver ces enclaves, les développeurs ont eux aussi tendance à modifier le code pour se créer du travail
Au fond, nous répétons nous aussi des changements pour le simple fait de changer