Le logiciel est le moteur de tous les aspects de l'économie. Au bas de l'industrie se trouvent les développeurs de logiciels. Les développeurs sont les artisans du logiciel. C'est super et pas si bien à la fois. Pas si terrible car ils sont souvent victimes de pressions et de frictions de la part de leurs collègues et de l'entreprise qu'ils servent.
Lors d'un déjeuner-causerie en ligne organisé par Parasoft, trois spécialistes en développement de logiciels ont discuté de sujets tels que la défense des intérêts des développeurs, l'accent mis sur la sécurité et les métriques DORA. Le titre du webinaire était Why Developer Advocacy Is the Key to Transforming Your DevOps Environment
Developer Advocacy est un mouvement informel mené par des techleads et des managers éclairés. Ils croient qu'un bon logiciel n'est possible que lorsque les développeurs sont correctement évalués par l'entreprise. Les enjeux pertinents au succès des développeurs consistent en :
- la sécurité psychologique
- la formation continue rémunérée pendant les heures de travail
- l'intégration attentive des nouveaux développeurs
- l'inclusion des développeurs dans la vision partagée des produits sur lesquels ils oeuvrent
besoins commerciaux
Les entreprises misant sur des logiciels ont besoin de rapidité d'exécution et de logiciels de qualité. Leur objectif principal est de commercialiser le plus rapidement possible. Atteindront-elles ces objectifs en gérant des projets avec des délais et en mettant la pression sur les développeurs ? Tracy Bannon (MITRE), Bryan Finster (Defense Unicorns) et Kevin E. Greene (Parasoft) sont contre.
Pour Bryan Finster "vous obtenez de la vitesse si vous travaillez correctement". Il souligne que la "fréquence de déploiement" mesuré par DORA est souvent considérée à tort comme une métrique de vitesse. Pour lui, la vitesse est le résultat d'un processus sain. Par exemple, l'excellence dans la « fréquence de déploiement » ne consiste pas à coder plus rapidement mais à déployer fréquemment de plus petits morceaux de code.
Tracy Bannon note que la "fréquence de déploiement" n'est pas une solution miracle. Certains domaines comme les agences gouvernementales, les logiciels embarqués et les industries réglementées ne bénéficieraient pas de multiples déploiements quotidiens en production. De façon réaliste, au lieu de déployer une fois tous les 2 ans, pouvoir déployer tous les 6 mois serait une grande amélioration dans ces domaines.
Elle souligne également qu'une clé d'un flux de développement sain est une boucle de rétroaction rapide : « fail fast - fail cheap ». Afin d'accélérer la boucle de rétroaction dans le développement de produits où l'erreur peut coûter des vies, on peut rédéfinir la notion de mise en production et considérer qu'un déploiement complet sur un simulateur en est une ; par exemple pour le développement de software pour un avion de chasse comme le F-35.
créer des équipes de produit et non des équipes de projet
Code, load, and hit the road
Tracy Bannon se souvient d'un dicton célèbre dans le monde de la sous-traitance : "codez, chargez et décampez". Malheureusement, développer un logiciel en tant que projet favorise le désengagement des développeurs. Ils subissent des pressions pour implémenter une liste de fonctionnalités et une fois cela fait, ils passent à un autre projet.
Les produits logiciels sains ne peuvent pas être construits en tant que projet. Malheureusement, au sein des grandes organisations et des agences gouvernementales, la conception des appels d'offre encouragent de telles défaillances dans le processus de développement et de cycle de vie du logiciel.
Les cabinets de conseil doivent promouvoir la qualité logiciel et la santé professionnelles des développeurs en éduquant leurs clients sur les principes fondamentaux d'un bon logiciel.
Un bon logiciel est construit par des équipes ayant une vision commune. Des développeurs soucieux du produit. Des développeurs soucieux des utilisateurs finaux.
promouvoir la formation des développeurs
Bryan Finster déclare carrément que "les collèges et les bootcamps ne produisent pas de bons développeurs". L'embauche de développeurs juniors implique la nécessité de les éduquer pour répondre aux besoins de l'entreprise. Tracy Bannon parle d'un recalibrage de leurs compétences.
L'enseignement est souvent déphasée par rapport à la réalité de l'industrie. Tracy Bannon utilise le terme influence forward en mettant de l'avant la nécessité, pour l'industrie du logiciel, d'aller dans les collèges pour discuter des compétences nécessaires aux futurs développeurs. Elle souligne que certaines grandes organisations technologiques sont déjà en relation avec certaines institutions académiques. Mais de telles initiatives sont encore rares.
Selon le panel, les développeurs ne réfléchissent pas assez à leurs objectifs et à leurs carrières. Ils utilisent souvent leur temps libre pour améliorer leurs compétences. Sans objectif à long terme en tête.
Bryan Finster déclare qu'il n'est pas acceptable que les développeurs aient à se renseigner sur la qualité ou la sécurité des logiciels en tant que projet 'à côté' ; en hobbyistes. Les meilleurs développeurs passent leur temps à s'améliorer ; d'une manière non formelle d'apprentissage. À leurs frais...
Lors des entretiens d'embauche, lorsqu'on leur demande comment ils se tiennent à jour et s'améliorent dans la technologie, la plupart des développeurs parlent de projets personnels et d'apprentissages réalisés pendant leur temps libre ; pas pendant les heures de travail.
Jusqu'à ce que les développeurs soient considérés comme des code monkeys, nous aurons besoin d'un plaidoyer des développeurs pour améliorer l'industrie du logiciel.
