Je rebondis sur un post récent de Rudy Onfroy (merci Rudy!)

Pourquoi, lorsqu’on est développeur, devrait-on apprendre en permanence ?

Ça ne va pas de soi. Un modèle plus “naturel” de l’évolution de nos compétences professionnelles, surtout si l’on se réclame de l’artisanat, consiste à acquérir des compétences, pendant les années de formation, puis à les appliquer tout au long de sa carrière et parfois à les transmettre.

Dans le domaine de la conception de logiciel, il en va différemment. Tout le monde ou presque défend le principe d’apprendre en continu, c’est à dire, non pas seulement durant des périodes moins actives, entre deux contrats, en stage ou le soir à la maison, mais tous les jours, sur la matière même du projet.

Qu’est-ce qui fait que nous devons continuellement apprendre ? Eh bien, la matière même du projet :

  • l’erreur est humaine; les plannings sont loin d’être parfaits; le contexte du projet change

  • nous promettons systématiquement plus que nous ne pouvons tenir (ce sujet mériterait des livres entiers)

  • globalement la “force de travail” est structurellement sous-formée (car la demande en compétences dépasse l’offre en formation, et le marché a horreur du vide).

  • en temps de crise dans le projet (et certains diront qu’un projet n’est qu’une crise en attente) nous sacrifions ce qui nous paraît avoir moins de valeur-produit :

    • la documentation (pour laquelle nous sommes de facto en déficit de compétences et de motivation)

    • les vérifications automatisées (ditto)

    • les relectures de code (qu’une majorité d’entre nous voit comme une hérésie de toutes façons)

    • le test (on préfère toujours un produit “complet” insuffisamment testé, qu’un produit incomplet testé adéquatement)

    • la rétro-analyse (débat moral obligatoire sur la question “pourquoi” dans 5P), et le débrief en général

    • la communication, notamment autour de la vision du projet/produit, qui est une communication difficile à établir et à maintenir (je compte sur les doigts de la main le nombre d’équipes en vision partagée que j’ai rencontrées ces dernières 30 années)

Sans un effort continu d’amélioration de ces pratiques, notre projet dévisse, parfois lentement, mais toujours sûrement.

Ce qui nous ramène à la métaphysique de la Dette Technique. La DT n’est pas une propriété du code, ou de la conception. La DT c’est votre état de l’art — c.à.d l’ensemble des pratiques, principes, modèles qui s’appliqueraient le plus adéquatement au problème posé dans le contexte donné — qui se dégrade.

Nous devons apprendre parce que nous recherchons en permanence, en partant d’un déficit, la meilleure adéquation possible entre nos pratiques et le problème posé.

Qu’un objectif ou une contrainte change, et une partie de notre état de l’art devient caduque, inopérante, voire contre-productive

Corollaire : dans un projet en crise, votre état de l’art est ce qui se dégrade en premier (avant même les résultats, ou le produit).

Learning

Publié sur Linked In le 30/08/2024