Whatever works
Point de critique de film ici (bien que je vous conseille tout à fait ce film de Woody Allen, datant de 2009), mais une réflexion sur son invitation au lâcher-prise. "Whatever works", ce titre m'avait marqué alors et revient régulièrement à mon esprit depuis quelques années, si bien qu'il m'a semblé intéressant d'expliciter son sens dans un contexte de développement de produit.
Ne soyons pas plus royalistes que le roi
Les échanges entre informaticiens font la part belle au dogme. Les batailles entre experts sont les plus violentes, alors même qu'ils s'accordent sur 97% du sujet (mais les 3% restants, quels 3% !) Souvent, ce n'est d'ailleurs qu'une affaire de définitions, si bien que, opérationnellement, ces personnes pourraient s'entendre. Exemple : l'Architecture Hexagonale vise-t-elle à isoler la logique du domaine ou bien, plus largement, la logique applicative ? Tout dépend évidemment de ce que l'on entend par "domaine". Et donc beaucoup d'énergie perdue, une énergie qui serait mieux investie à discuter avec des personnes éloignées de ce que l'on s'accorde à définir comme les bonnes pratiques du développement logiciel.
Justement, si seulement 50% de ces pratiques étaient adoptées effectivement par les équipes, nous nous en porterions tous bien mieux (utilisateurs, product managers et développeurs, sans oublier votre serviteur).
Quelques exemples :
- Le Test-driven development : très bien, mais c'est le nec plus ultra. Si déjà il y avait des tests, seulement des tests unitaires écrits après développement (Test After), ce serait mieux que rien et déjà beaucoup.
- Autre exemple : nous sommes nombreux à reconnaître les mérites de la Pyramide de tests . Mais si une équipe préfère écrire des tests de plus haut niveau et que cela fonctionne dans la durée, tant mieux (et j'aurais envie d'y regarder de plus près pour comprendre pourquoi cela marche).
- Dernier exemple : les tests doivent être exécutés par la plateforme d'intégration continue, c'est une évidence. Mais parfois, c'est difficile, en particulier pour des tests qui demandent de monter une base de données. Alors, dans un premier temps, les exécuter localement, avant de pousser les développements, cela apporte déjà de la valeur et constitue une étape à part entière.
Du pragmatisme, s'il vous plaît
C'est l'occasion de rappeler que les bonnes pratiques sont nombreuses et bien établies, mais qu'elles n'ont de sens la plupart du temps que pour des cas d'usages précis. Un seul exemple : 100% de votre codebase n'a pas à être écrite en TDD, ce serait tomber dans la tristement fameuse loi de l'instrument .
Il ne s'agit donc pas de réduire nos ambitions mais de faire preuve de pragmatisme et de s'adapter à la situation : les problématiques diffèrent selon le métier, source de tout pragmatisme, et la taille des équipes, sachant que l'équipe de 1 personne est un cas-limite courant. Les bonnes pratiques doivent être comprises, questionnées et peut-être interprétées. Par la suite, le temps devrait être notre seul juge de paix : si une équipe tient le rythme sur la durée et se satisfait du travail qu'elle fournit, que dire de plus ?
Au final, supposant acquis que nous cherchons à bien faire, nous pouvons nous ôter un peu de culpabilité. C'était d'ailleurs le sens du coup de gueule de David Heinemeier Hansson dans son article TDD is dead. Long live testing. , DHH à qui l'on ne saurait dénier un excellent track record. Je ne suis d'accord avec presque aucune des positions qu'il exprime dans cet article, mais je comprends parfaitement son ressenti. Que quelqu'un travaillant avec moi puisse avoir ce ressenti m'ennuierait, et je serais probablement prêt à revoir mes positions pour y remédier.
Le doute comme moteur
Au-delà, ce "Whatever works" est une question de doute. Et en disant cela, il faut distinguer deux types de situations :
- Situation 1 : ce que vous vous apprêtez à faire est une ignoble bêtise, vous foncez droit vers la falaise. En pareille situation, je défendrai le bifteck un certain temps, quel que soit mon rôle vis-à-vis de l'équipe.
- Situation 2 : je doute de l'idée, je ne le vois pas, mais le risque n'est pas immense, alors allez-y et reparlons-en rapidement – garder une boucle de feedback rapide, un investissement minimal pour l'éventualité où il faudrait réajuster le tir.
Dans ce second cas, il serait en fait intéressant et pour tout dire souhaitable d'avoir tort, parce que cela serait la preuve que mon modèle mental des choses ne fonctionne plus et que, face à cette nouvelle situation, il faut adopter un modèle plus large, plus englobant, prenant en compte plus de paramètres. Autrement dit, je serais ravi d'avoir tort.
Le doute nous incite donc à laisser des portes ouvertes. Il peut être inconfortable, mais c'est un inconfort qui fait avancer, un inconfort qui élargit les horizons et permet d'aller plus loin.
Cette position suppose bien sûr que l'on s'accorde sur un objectif commun : rechercher ce qu'il y a de meilleur pour le produit, le projet ou l'équipe. Le but n'est pas d'avoir raison, mais de trouver ensemble la meilleure solution, qui est rarement une position très tranchée. L'art de la nuance. Et pour cela il faut écouter les faits et s'y ranger.
J'enfonce des portes ouvertes, mais cela suppose de l'honnêteté partagée, une envie de bien faire inscrite dans la culture d'entreprise. Au fond, si ce cadre est acquis, que vous discutez dans l'objectif de construire ensemble un peu plus de vérité, c'est que vous parlez de pair à pair et que vous vous êtes bien trouvés. Un critère-clé en matière de recrutement .
Douter pour mieux défendre ses convictions
Ne me taxez pas de relativisme : l'idée que tout se vaut est une idée que j'abhorre. Certaines choses ne fonctionnent pas, c'est éprouvé et documenté – laisser courir votre dette technique, par exemple. Mais peut-être faut-il justement avoir beaucoup douté pour être en mesure de défendre énergiquement un sujet auquel on croit. Le doute, honnête, est là pour vous aider à faire la part des choses : discussion après discussion, on voit bien si une idée tient ou non.