Avoir moins de fonctionnalités peut engendrer un meilleur produit, d'après le concept "Worse is Better" décrit il a 25 ans par Richard P. Gabriel. Selon Kevlin Henney et Frank Buschmann, nous pouvons nous inspirer de ce concept pour le développement et l'architecture en agile et en lean.
Lors de la Conférence OOP 2015 qui s'est tenue fin janvier, Kevlin et Frank ont animé la session "Worse is Better, for Better or for Worse". Durant leur intervention, ils ont exploré une manière, centrée sur le produit - et l'architecture, de réfléchir au développement itératif et incrémental, et ont expliqué comment la gestion de la qualité et du périmètre peut aider à créer un logiciel réussi.
InfoQ a interviewé Kevlin et Frank à propos du concept Worse is Better, de la façon dont l'utiliser dans la conception logicielle, des différences entre les approches "Good Enough Software" et "Worse is Better", ainsi que comment ce concept peut être appliqué au développement logiciel agile et lean.
InfoQ : Pouvez-vous nous expliquer l'idée qui se cache derrière le concept "Worse is Better" ?
Kevlin : Worse is Better a initialement été inventé et décrit par Richard Gabriel, il y a 25 ans. Le nom est un peu déroutant, puisqu'il ne suggère pas que le logiciel devrait être moins bon dans le sens où beaucoup de gens considèrent un logiciel comme étant bon ou mauvais - à savoir, le pourcentage d'anomalies, les performances et la qualité ; mais moins bon dans le sens où l'on réduit le périmètre d'une vision plus ambitieuse de ce que le logiciel devrait couvrir. Un produit "worse is better" est développé incrémentalement à partir d'une sélection minimale de fonctionnalités, tout en assurant une bonne implémentation et de bonnes performances.
Frank : J'aime bien la définition donnée par Wikipédia : "L'idée de Worse is Better est que la qualité n'augmente pas forcément avec les fonctionnalités. Il arrive un moment où moins de fonctionnalités ("worse") est une option préférable ("better") en termes de praticité et de facilité d'utilisation. Un logiciel qui est limité, mais simple d'utilisation, peut être plus attrayant pour l'utilisateur et le marché, plutôt que l'inverse".
InfoQ : Quelles sont les caractéristiques d'une conception logicielle Worse is Better, pouvez-vous nous les décrire ?
Frank : Commencez avec une sélection minimale de fonctionnalités, et gardez la conception du logiciel simple tout en respectant son implémentation. Assurez-vous que la conception logicielle est correcte sur tous les aspects importants, qu'elle ne comprend pas de bugs, et qu'elle s'exécute rapidement. Implémentez le logiciel en utilisant un logiciel existant (du marché), ainsi que des outils avec lesquels les utilisateurs sont familiers.
Kevlin : Commencez petit, restez simple, soyez tolérants vis-à-vis des bugs, rendez-le rapide, ne vous perdez pas en abstraction, servez-vous des logiciels et infrastructures existantes.
InfoQ : Pourriez-vous nous donner votre avis sur l'approche "Good Enough Software". En quoi est-elle différente de "Worse is Better" ?
Kevlin : Le choix des mots fait que l'approche Good Enough Software est souvent confondue avec l'approche Worse is Better, mais elles sont presque contraires dans leurs caractéristiques. Le "good enough" dans "Good Enough Software" se réfère à la qualité intrinsèque : la gestion des anomalies, la qualité du code et les performances ne sont pas priorisées ou gérées comme des qualités critiques. La focalisation se fait sur les dates d'échéances, à commencer par le time to market. Alors qu'une approche de ce type peut montrer des résultats sur le court terme, elle ne présente que peu de sens économique sur le long terme - les coûts et délais accidentels provoqués par les problèmes de qualité tendent à définir le développement plus que les fonctionnalités.
Frank : Le Good Enough Software cible le time to market : le premier produit dans un segment de marché, qui est suffisamment riche en fonctionnalités et stable pour un large éventail d'utilisateurs, gagne la plus grande part du marché. Et ceci même si sa conception et son implémentation manquent de qualité et présentent des bugs, et même si de meilleurs produits concurrents sont disponibles plus tard dans le temps. En résumé, le Good Enough Software valorise le time to market et la gestion des anomalies plutôt que la haute qualité de produit initiale.
InfoQ : Le concept de Worse is Better a été proposé par Richard P. Gabriel il y a 25 ans, mais nous avons encore des choses à apprendre grâce à lui. Pouvez-vous nous expliquer pourquoi et nous donner des exemples ?
Frank : Nous, en tant que communauté de développement logiciel, avons toujours tendance à sur-développer nos systèmes. Des fonctionnalités dont peu d'utilisateurs, sinon personne, ont besoin, une généricité extrême, de la flexibilité et de la variabilité en préparation de changements qui n'arriveront jamais, et ainsi de suite. Le résultat de ce type de réflexion est une conception onéreuse à implémenter, stabiliser, et faire évoluer à un coût raisonnable et dans les délais attendus par le marché, à cause de sa haute complexité accidentelle et de sa dette technique. Worse is Better nous offre un système de valeurs pour savoir comment se focaliser sur l'essentiel - créer un produit viable minimum qui soit simple à implémenter et à utiliser. Si le produit est réussi, nous pouvons le faire évoluer de façon incrémentale à partir de là, en se basant sur les besoins réels des utilisateurs et "l'expérience terrain". Cette approche s'est avérée fructueuse pour de nombreux systèmes, allant de systèmes de domotique orientés clients pouvant être controlés via des applications smartphone ou tablette de n'importe où, à des systèmes de commande pour les détaillants dans des domaines ayant des infrastructures IT peu fiables. Selon moi, le concept d'apps est aussi quelque chose qui suit le Worse is Better. Les bonnes apps ont une sélection de fonctionnalités petites, mais puissantes, sont intuitives et faciles à utiliser sur une infrastructure familière, et elles sont rapides.
Kevlin : Nous voyons encore tellement de projets qui s'embourbent dans une complexité accidentelle, surchargés par des fonctionnalités qui ne sont pas nécessaires ou mal choisies et qui accumulent de la dette technique et des anomalies. Se concentrer sur une implémentation simple et rapide plutôt que sur une généricité spéculative, et être intolérant aux bugs plutôt que les accumuler, ferait une grosse différence dans la vie du produit comme dans celle des développeurs.
InfoQ : Pouvez-vous nous donner des exemples d'application du concept Worse is Better en développement agile ou lean ?
Kevlin : A moins qu'un problème ait un périmètre délimité et qu'il soit complètement défini, un processus de développement doit être plus empirique que planifié. De cette façon, un produit et son architecture peuvent être traités en tant que combinaison d'hypothèses, chacune d'entre elles devant être comprise et explorée - une composante si l'hypothèse est avérée, jetable si ce n'est pas le cas. Cela correspond au modèle incrémental des approches Agile et Lean, mais en ajoutant de l'importance sur les caractéristiques de performance et d'implémentation.
Frank : Selon moi, Worse is Better est en fait un système de valeurs ou une sélection de lignes directrices pour développer un bon produit, une sorte de definition of done en termes de fonctionnalités produit, de conception générale et de qualité d'implémentation. Que ce produit soit développé en mode agile ou lean, ou avec n'importe quel autre processus de développement, cela n'a pas d'importance. On peut dire que les pratiques agiles, comme le développement incrémental et la livraison continue, ainsi que les pratiques lean, comme l'élimination du gaspillage, sont les piliers du concept Worse is Better. Cependant, ce raisonnement est aussi applicable à d'autres sytèmes de conception de valeurs, comme par exemple le Good Enough Software. Personnellement, je trouve ce genre de discussions plus théoriques que pratiques. Les entreprises de développement qui prônent le Worse is Better trouveront des moyens de créer des produits Worse is Better.