Le coût de l’inutile

Dans le merveilleux monde du développement logiciel il n’y a rien de pire que des fonctionnalités non utilisées, soit par ce qu’elles ont été développées trop tôt (le client n’en a pas encore besoin) soit parce qu’elles ne rencontrent pas le marché attendu (mauvaise compréhension du marché). Leurs coûts ne doivent pas être calculés uniquement sur leurs coûts de développement, ils doivent aussi inclure les coûts « collatéraux ».

« You Aren’t Gonna Need It »

J’ai récemment lu l’article de Martin Fowler sur le principe YAGNI, un principe venant de l’eXtreme Programming (XP). Le principe YAGNI stipule que nous ne devons pas ajouter de nouvelles fonctionnalités à notre logiciel tant que celles-ci ne sont pas jugées nécessaires. Ce principe tend à combattre le fameux « tant qu’à… » dont nous sommes souvent victimes.

En tant que développeurs cela se traduit par notre aversion à dépasser la portée du récit utilisateur (User Story) sur lequel nous travaillons. Tant qu’à travailler sur ce récit utilisateur, pourquoi nous n’en profiterions pas pour ajouter/modifier…. De plus nous risquons de tomber dans un cercle vicieux du « tant qu’à… ». Car il y a toujours un « tant qu’à… » à un « tant qu’à… ».

Cela à plusieurs implications :

  1. nous retardons ainsi la disponibilité de la fonctionnalité que nous devions livrer, le retour sur investissement est donc lui aussi retardé.
  2. nous ajoutons de la complexité dans le code de la fonctionnalité que nous devions livrer, cela implique plus de tests et un entretien plus difficile.
  3. nous décalons la livraison de fonctionnalités qui sont plus prioritaires, nous impactons donc le plan de livraison. De plus ce dernier a pu être bâti en tenant en compte de travaux coordonnés entre plusieurs projets, nous retardons alors les livraisons de plusieurs autres projets.

Toutes ces implications induisent des coûts collatéraux!

Une fonctionnalité non utilisée s’appelle une dette!

Il nous arrive parfois d’avoir un regard objectif et critique sur les logiciels que nous développons et nous nous apercevons alors (grâce à l’instrumentation du code source notamment) que les fonctionnalités que nous pensions si utiles à nos utilisateurs ne sont que rarement utilisées. C’est à ce moment-là que nous prenons conscience du temps passé, livraison après livraison, à entretenir et exécuter des tests de régression (automatisés ou non) pour des fonctionnalités que (presque) personne n’utilise. Le temps n’est-il pas de l’argent?

Michael Feathers, dans son article intitulé « The Carrying-Cost of Code: Taking Lean Seriously », nous recommande d’effacer le code des fonctionnalités non utilisées afin de réduire la complexité (inutile) du code de nos applications. Nous bénéficierions ainsi d’un code source pour lequel les efforts d’entretien et d’évolution seront réduits, nous offrant, par conséquence, la possibilité de livrer plus vite.

Retarder ses livraisons à un coût celui d’arriver sur le marché après ses concurrents!