Les faux progrès
Une introduction où l'on parle de café, pour revenir ensuite à l'informatique.
J'ai un temps possédé une machine à café qui consommait des capsules en aluminium vendues par un bellâtre, Georges de son prénom ☕️
Ladite machine était conçue pour perforer automatiquement la capsule afin de me faire gagner de précieuses secondes à moi, jeune cadre aussi dynamique qu'ambitieux. Secondes que j'utilisais pour exercer à plein ma créativité, créer 3 entreprises, changer le monde et… non, pour tenter de déloger cette fichue capsule qui s'était une fois de plus mal engagée (1 fois sur 10 environ).
Donc tout un mécanisme et de l'électronique, toute une complexité additionnelle pour m'éviter d'actionner manuellement un levier et faire marcher mes petits muscles par la même occasion : on n'arrête pas le progrès…
Les exemples de faux progrès sont nombreux : couteau électrique, ventilateur de poche, fontaine à eau pour chat, souffleuse à feuilles, jusqu'à l'hypothétique salière connectée qui, espérons-le, tient plus du mème que de la réalité. Et quand, un samedi soir, ma chasse d'eau se met à fuir dans les grandes largeurs, je me dis que la cruche à eau avait du bon. Moi, Amish ?
Mais revenons à nos logiciels.
Quand on développe un produit, il y a souvent cette fonctionnalité que l'on introduit et qui décuple la complexité du code. L'existant devient un simple cas particulier, on monte d'un cran en termes de généricité, boudu quelle puissance je suis le maître du monde. On se calme.
Parfois, cette complexité a lieu d'être, parce qu'elle rend un service qui nous démarque de la concurrence… et parfois non. Ou, pire, l'expérience utilisateur y perd et l'on bascule dans le feature bloat : l'ajout de la fonctionnalité fait perdre de la valeur à l'application dans son ensemble.
Le feature bloat est dramatique car, outre la dégradation de l'expérience utilisateur, la complexité induite par la fonctionnalité ralentit le processus de développement en même temps qu'elle accroît le risque de bugs. Parfait pour perdre des utilisateurs.
Mieux vaut donc prendre le temps de "challenger le besoin" avec ces derniers, revenir sans cesse au "pourquoi" (5 whys), peser le pour et le contre et imaginer si nécessaire des solutions de contournement. Tout le travail et toute la valeur ajoutée de nos amis Product Managers.
Malheureusement, la concurrence pousse les entreprises à proposer des produits qui font Papa, Maman et le café. Le SRP (Single Responsibility Principle : ne faire qu'une chose mais la faire bien) n'est pas toujours simple à vendre, notamment pour des raisons d'interopérabilité entre applications.
Mais j'aurais tendance à dire : en matière de fonctionnalités, mieux vaut manquer que d'avoir trop. Si vraiment tous les signaux vous crient que vous ne pouvez plus faire sans cette fonctionnalité, il sera encore temps de l'implémenter avec la conviction que la complexité qu'elle apporte est un mal nécessaire.