Où apprendre et s'améliorer ?
Dans une entreprise qui manufacture des produits, pour peu qu'elle soit gérée dans une approche d'amélioration continue, l'amélioration se produit sur le lieu de travail, et non en dehors. Ses managers n'exigent pas des employé·es qu'ils ou elles améliorent leur travail le soir ou le week end, en pratiquant chez eux 5S, jidoka ou kaizen. 🧱
Dans la plupart des entreprises où l'on développe du logiciel, l'apprentissage se produit en grande partie hors du lieu et du temps de travail. 🛋️
Si vous êtes un·e développeur·se, ou tech lead voici une question pour vous :
Imaginez vous et votre équipe ayant travaillé tout ce temps sur votre projet (6 mois, 1 an, 5 ans ?) sans aucun recours à votre ordi perso, mais uniquement sur le matériel et les horaires du projet. Pensez-vous que l'état de l'art de votre équipe serait au niveau où il se trouve actuellement ?
Dans le développement logiciel, des pratiques telles que 5S, ou Jidoka n'ont pas leur équivalent (immédiat). Et pour ce qui est du standard on s'en remet à l'idée commune que l'on se fait de l'état de l'art du moment sur le marché.
Une approche d'amélioration continue spécifique au développement logiciel doit inclure à mon sens les pratiques essentielles de prévention des défauts et de réduction de la "friction" que présente toute base de code existante :
- tests à grain fin, automatisés, permettant de sécuriser le comportement du code contre les régressions
- relecture du code, permettant de tuer dans l'œuf les défauts de conception
- refactoring en continu, assurant la fluididité de la communication des idées dans le code
Or ces 3 pratiques ne sont pas "mainstream", loin de là. Elles sont rassurantes à lire sur un CV, mais ne sont pas encouragées une fois sur le terrain, parce qu'elles entrent en conflit avec les échéances intenables et les livraisons en retard, aggravées par les problèmes de qualité. 🚒
Elles font également l'objet de controverses sur les réseaux sociaux. Les développeurs forment une population jeune, qui n'hésite pas à casser les vieux préceptes sur la base d'une expérience insuffisante, ce qui fait le ravissement des courtiers en idées nouvelles. Relire du code ensemble, quelle idée terriblement 20ème siècle. Les tests unitaires ? Une perte de temps. 😎
Ces controverses arrivent jusqu'à l'entreprise, où elles renforcent le barrage fait aux pratiques éprouvées. "Aucune étude ne démontre l'efficacité de TDD". Aucune étude ne démontre l'efficacité du Code & Fix non plus, mais cela ne change rien : en s'appuyant sur les acquis individuels d'artisans logiciels qui s'instruisent à la maison, au lieu de faire de l'amélioration continue en équipe le cœur de l'apprentissage, l'entreprise encourage le turn-over et s'enfonce dans le legacy.
Beaucoup d'entreprises se demandent comment garder leur développeur·ses. Suggestion : faire en sorte qu'on apprenne plus facilement chez vous en équipe que tout·e seul·e sur internet.