Produit : quand on s'attache à son bébé

Jeune développeur, je ne jurais que par le "greenfield" : n'ayant pas les clés méthodologiques et architecturales pour passer de codebases de 10 000 à 100 000 SLOC (Source Lines Of Code), je sautais de projet en projet, repartant à chaque fois sur de meilleures bases sans jamais réussir à franchir le palier de l'ordre de grandeur.

Avec le temps, j'ai trouvé quelques-unes de ces clés. Elles sont venues au gré de mes lectures, de mes expérimentations et des échanges avec mes pairs. Ces clés m'avaient tellement manqué que j'en ai fait le cœur de mon expertise, la qualité logicielle. J'en découvre encore, fabrique parfois les miennes et en cherche constamment de nouvelles.

Quelles sont-elles, au fait ?

• Des clés relatives à la cible ("qu'est-ce qu'un logiciel bien fait ?") : modularité, architecture, stratégies de test et d'écriture de code guidé par les tests et, avant toute chose, les principes du clean code ;

• Des clés relatives aux divers chemins menant à la cible, j'entends par là les méthodes de refactoring : Golden Master, Méthode Mikado, Strangler Fig Pattern… Tellement peu connues et tellement essentielles.

Tandis que mes compétences se développaient, mon plaisir a évolué. J'ai appris peu à peu le charme discret du "brownfield", cette codebase que l'on fait grandir et dont on prend soin comme d'un enfant. On corrige le bug d'un produit comme on soigne un enfant ; on ajoute de nouvelles fonctionnalités au premier comme on enseigne au second ; on fait évoluer le modèle applicatif comme on propose une vision du monde à un enfant pour l'aider à s'adapter. On pourrait filer la métaphore plus loin encore.

Cet enfant, ce produit, on veut beaucoup de choses pour lui, on est ambitieux, parfois trop peut-être. Le produit est ce qu'il est, avec ses forces et ses faiblesses. On prend soin de lui jour après jour, on le répare, on l'améliore, on le fait grandir, mais avant tout, on l'accepte et on l'aime tel qu'il est aujourd'hui, sans attendre… En espérant toutefois qu'il ne devienne pas un horrible produit boutonneux à l'adolescence 😱

À bien y regarder, ce cheminement personnel n'est pas étranger à l'avènement de l'agilité, qui a déplacé le focus des projets vers les produits. Un projet se définit par sa fin : une fois que le périmètre fonctionnel est atteint, l'équipe est démobilisée et l'on passe en maintenance. Les développeurs, quant à eux, sont appelés sur de nouveaux projets, d'où l'orientation "greenfield".

Un produit, par contraste, n'a pas de fin a priori. On lui souhaite une longue vie, guidée à chaque instant par le retour d'expérience de ses utilisateurs. Comme un enfant devenant à terme un sujet autonome et doué de volonté, le produit nous échappe : on ne sait pas ce qu'il va devenir, mais on l'aime. Pourtant, l'équipe chargée de le développer est là, comme les parents sont toujours là pour leurs enfants. D'où l'orientation "brownfield".

Selon vous, est-il problématique de s'attacher au produit que l'on développe ?