Les bonnes pratiques en développement : un pari sur l’avenir

Combien de fois ai-je entendu quelqu’un s’exclamer : « Mais pourquoi il a fait ça comme ça?! » en parlant du code ou de l’architecture produit(e) par une autre équipe ? Et combien de fois l’ai-je moi-même dit.

Ce genre de phrase peut être déclamé, avec plus ou moins de mauvaise humeur, dans 2 cas de figure:

• Ce qui a été fait ne suit pas les « bonnes » pratiques : l’usage est alors de brandir un crucifix ou équivalent;
• Ce qui a été fait suit les bonnes pratiques, mais le besoin sous-jacent ne justifiait a posteriori pas de sortir la grosse artillerie. L’usage est alors de souffler très fort en secouant de la tête, en casant « pragmatisme » dans les phrases qui suivent.

Lorsque je me surprends à tomber dans l’un ou l’autre de ces cas de figure, je m’efforce de me taper sur les doigts pour me rappeler de temporiser – un minimum – mon jugement.

La première question à se poser est :

 

Qu’entend-on par « bonne pratique » en développement ?

 

 

Une « pratique » est un ensemble de conventions ou de manières de faire partagé par une communauté, par exemple une équipe de développement ou une entreprise.

La pratique ne devient « bonne » que lorsqu’elle a fait la preuve de son efficacité de manière répétée. La question est donc de savoir par rapport à quoi on juge qu’elle est efficace.

 

Une bonne pratique est définie par ses objectifs et son contexte

 

En effet une bonne pratique n’est pas absolue. On peut résumer une bonne pratique comme étant la recette réputée efficace que l’on applique au croisement:

• D’un contexte : technique, technologique, culturel, … Par exemple, un principe comme API-first ou Event-Driven First peut être un élément structurant de la culture de l’entreprise;
• D’un besoin : tout l’effet que le bout de code ou de solution est censé produire;
• Et d’indicateurs de « performance » que l’on souhaite optimiser : temps de réponse, débit, lisibilité… A noter que ces indicateurs ne sont pas nécessairement mesurables : on va par exemple souvent retrouver la maintenabilité ou l’évolutivité parmi ces indicateurs.

Tous ces éléments ne sont rien d’autre que des hypothèses de travail. Or le propre d’une hypothèse est qu’elle peut être invalidée. Soit d’emblée (ce qui peut souvent être le cas dans le cadres de PoCs par exemple), soit plus tard.

 

Adopter une bonne pratique : la projection dans le temps

 

 

La dimension temps est donc centrale à deux titres :

• Les hypothèses peuvent changer dans le temps. Par exemple : on choisit initialement de favoriser la fiabilité, pour ensuite choisir de maximiser le temps de réponse (coucou le théorème de CAP);
• Certains KPI font explicitement référence au futur. Par exemple : l’évolutivité. On peut ainsi chercher à optimiser quelque chose qui se trouvera en fin de compte être sans objet. Dans le cas de cet exemple, la solution sera peut-être purement et simplement décommissionnée, sans avoir fait l’objet d’évolutions. Autre exemple : on peut parier sur un nombre démesuré d’utilisateurs concurrents de la solution par rapport à ce qu’il sera réellement.

Le problème ici est qu’on ne peut pas prédire l’avenir : on doit donc faire des choix en sachant que l’avenir peut nous donner tord. En revanche on sait très bien ausculter le passé et constater le présent. Et c’est là que le présentisme pointe le bout de son nez.

 

Attention au biais de présentisme

 

On peut donc être tenté de juger aujourd’hui une solution à partir de ce qu’on sait (ou croit savoir …) du passé et du présent et non de ce qu’on pensait savoir ou imaginait à l’époque.

A chaque fois que l’on se tape le front en lâchant un juron devant le code ou la solution d’un autre, il conviendrait en réalité de se demander :

• Quelles étaient les hypothèses initiales?
• Ces hypothèses sont-elles toujours les mêmes aujourd’hui?

Ces simples questions permettent d’éviter de tomber dans le piège du présentisme ou biais rétrospectif, c’est à dire de juger les décisions passées à la lumière des connaissances actuelles. Mais alors, comment être sûr de connaître les hypothèses initialement retenues ?

 

Eviter l’amnésie en documentant les choix

 

Documenter les décisions est généralement un bon point de départ. Dans le contexte du développement logiciel, une réponse peut être de rédiger des Architecture Decision Records (ADR), qui permettent d’archiver les décisions techniques, le contexte et les alternatives envisagées. Ils aident à contextualiser et comprendre les choix passés, permettant ainsi de faciliter la maintenance de la solution.

D’ailleurs, si les ADRs sont efficaces pour répondre à un besoin (documentation des choix passés), dans un contexte (le développement logiciel) et avec un objectif d’optimisation en tête (maximiser la maintenabililté), ne suis-je pas en train de dire que les ADRs sont … une bonne pratique ? 😬

 

Conclusion

 

En fin de compte, je dirais que choisir d’appliquer ou non telle ou telle pratique reste fondamentalement un pari sur l’avenir très fortement dépendant du contexte. Un pari que l’on juge relativement sûr étant données les hypothèses et les expériences passées, mais malgré tout ni plus ni moins qu’un pari.