— Qu’est-ce qui pourrait te convaincre de rester ? demande le manager au développeur démissionnaire.

— A minima, pouvoir travailler avec du code maintenable.
— Qu’est-ce qui vous empêche d’écrire du code maintenable ?
— Sérieusement ? Viens au prochain sprint planning, et tu verras.
— Justement, votre P.O. me dit que vous passez trop de temps sur le refacto.
— Tu n’as qu’à lui dire que la qualité du code, c’est important.
— Tout est important…

🤹

Trois acteurs aux objectifs complémentaires mais distincts s’impliquent dans ce projet. Aucun d’eux ne peut avoir seul le dernier mot sur sa direction.

📲

Le Métier vise une solution qui réalise de la valeur, dans les meilleurs délais et pour pas trop cher. Le code ? C’est un moyen : si l’on pouvait se passer d’en écrire, le projet s’en porterait très bien. Pourquoi pas ? Le monde de la technologie nous raconte une épopée miraculeuse faite de miniaturisation, d’intégration, d’automatisation, d’industrialisation, de transformation… C’est pour bientôt !

👩🏽‍💻

La Technique veut maximiser l’apprentissage. Non pas l’apprentissage en général — quoique la généralisation soit une seconde nature chez les développeurs — mais celui nécessaire à la résolution de ce problème particulier décrit par le Métier, qui est un problème ouvert. Le Métier formule le souhait d’une solution, mais ce qui va voir le jour c’est un flot d’activités (informatique, cognitive, financière, logistique, etc.) en constante évolution, et non pas une solution figée. Le contexte, les objectifs, les contraintes de ce problème vont changer, avant même la première “livraison”.

📝

La Technique doit donc, en plus de résoudre le problème, tracer et documenter, souvent dans le code lui-même, ses intentions et ses limites face aux évolutions possibles du problème. Pour reprendre Peter Naur, il faut non seulement un programme, mais également une théorie qui sous-tend ce programme. Les outils modernes pour décrire cette théorie s’appellent Refactoring, Architecture Decision Record, Ubiquitous Language, Test Driven Development…

🎛

Le Management voudrait rendre ce problème (le problème de créer de la valeur à l’aide de la technologie, et dont les frontières vont se déplacer) manageable. C’est essentiel. Un manager pose souvent les questions “Combien ?”, “Qui ?”, “Quand ?”, “Avec quelles garanties ?”. Sans ces questions, et sans l’insistance du Management, le Métier se bercerait d’illusions, et la Technique exploserait son budget en recherche, plutôt qu’en développement.

Pour revenir au projet dont il est question en introduction, nos 3 acteurs ont chacun joué une carte :

🏭 Le Management a normalisé toute l’activité dans un modèle de type “production” simple, clair, hiérarchisé

🗜 Le P.O. fait pression pour qu’on sacrifie la maintenabilité de demain aux résultats d’aujourd’hui

🚪 Le Tech Lead a trouvé un contexte plus favorable à ses aspirations quitte à déstabiliser le projet

Qui va gagner ?

Stay Tuned !

publié sur LinkedIn le 07/03/2023