- 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
Aucun commentaire pour le moment.