Notre difficulté principale, ce n’est pas de mettre en œuvre une application basée sur la technologie, c’est plutôt de maintenir la cohérence de l’état de l’art qui guide son évolution.

La technologie change constamment, et nous nous employons à la faire marcher. Nous y consacrons pas mal de temps, d’argent, d’énergie et de motivation, souvent trop, mais on s’en sort. Nous adorons, au sens religieux du terme, les nouvelles technologies. Or celles-ci s’empilent, mais ne s’emboîtent pas.

Toute équipe qui réalise du logiciel doit faire évoluer simultanément a) le produit b) la conception et c) son état de l’art.

Au siècle dernier ces évolutions étaient plutôt lentes (comparativement) du fait que les outils étaient moins puissants, moins accessibles, et moins bon marché. Nous ne sommes pas devenus de meilleurs ingénieurs : nous avons plus facilement accès à plus d’outils plus puissants.

Nous vivons donc dans une abondance technologique quasi-miraculeuse. Les outils, les langages, les modèles, les frameworks, les “solutions” se multiplient. Au sein de cette abondance, comme en présence de tout phénomène d’agrégation, l’entropie gouverne : il est plus simple de laisser l’accumulation se produire que de la réguler.

Voici quelques tâches incombant à l’équipe, classées par ordre croissant d’énergie requise en vue de préserver la cohérence :

🙂 copier/coller un bout de code

🤨 factoriser le code

😛 commenter du code devenu inutile (on ne sait jamais)

😅 supprimer le code

😎 travailler en solo

😒 aborder le code en revue ou en binôme

🤗 ajouter des fonctionnalités

😬 faire patienter une direction métier

🤓 faire confiance au leader

🤔 douter ensemble de notre solution

Pour s’organiser, pour améliorer en continu notre produit, notre conception et notre état de l’art, il faut se parler. Cela représente un travail considérable, souvent inconfortable.

Actes de naissance d’une dette technique :

🖋 On est en retard parce qu’on a sous estimé la complexité de la story; par conséquent je propose qu’on saute la revue et qu’on fasse moins de tests.

🖋 Le CV de Victor mentionne TDD, mais il avoue que dans “son TDD”, le cycle Test/Code/Refactor est tout à fait optionnel. De plus il trouve qu’on est un peu des “puristes du TDD”.

🖋 L’équipe passe la moitié du planning game à discuter d’une implémentation. Lorsque le PO s’impatiente on lui dit : tu veux une estimation oui ou non ?

🖋 Il est décidé qu’on produira des APIs. Qui les documentera, qui aidera les projets client à tester : cela reste à déterminer.

Non seulement nous ne sommes pas très versés dans ces conversations, mais nous sommes réticents à les tenir.

🖋 Je hais les réunions !

🖋 Fais plutôt un ticket

🖋 Mes remarques en bleu dans le mail

Nous avons tellement le sens des outils, et si peu celui des échanges, que d’après nos pronostics, le babil d’une intelligence mécanique colossale pourra bientôt nous dispenser d’employer des développeurs !

Stay Tuned !

publié sur Linked In le 10/02/2023