Catégories
Vie de freelance

Créer une culture de la qualité logicielle.

Parlons indicateurs, performance et surtout incentives. J’ai encore vu cette stupidité sur une offre de mission en Devops :

Imaginons que je sois un joueur sans scrupules, dans un jeu que l’on appelle « développement ». Ces règles du jeu m’encouragent à produire rapidement le code le plus ignoble possible, afin de trouver un maximum de bugs en phase de recette. Je serais ainsi félicité par mon manager et gratifié d’un joli bonus. Mon code sera couvert par des tests de régression, garantissant a minima que l’existant tombe en marche, mais mon intérêt est que chaque nouvelle fonctionnalité soit la plus sale et buguée possible. Ces règles du jeu encouragent les pompiers pyromanes.

Suis-je dans la caricature ? Bien entendu. De tels développeurs sont rares en sortie d’école. Mais ils peuvent le devenir, c’est là toute la magie des incitatifs (incentives en Anglais). Je voulais introduire mon propos en abordant le développement de logiciels sous l’angle de la théorie des jeux.

Psychologie du groupe

Un manager décide de recruter toute une équipe de juniors, en contractualisant leurs objectifs. Au départ, personne ne prête attention à ces indicateurs, ils ne génèrent ni récompense, ni sanction. Chacun fera du mieux qu’il peut, ou pas selon les jours. L’objectif ne deviendra visible qu’après quelques fiches de paie, comparées à la machine à café. Les joueurs prennent petit à petit connaissance des règles.

Prenons deux développeurs de cette équipe. Alice pratique le TDD et ne pousse jamais un code qui ne soit pas dûment testé. Bob modifie le code, vérifie que les tests préexistants passent, mais n’en rédigera de nouveaux qu’en cas de bug. En effet, si un bug recensé réapparaît, c’est une régression, donc un malus sur salaire. Bob est malin.

Arrive le passage en recette. Le code d’Alice ne pose que peu de problèmes. Celui de Bob, non testé, va générer de nombreux bugs. Subjectivement, le manager verra une Alice sereine, faisant ses heures normalement, sans stress. A contrario il observera que Bob ne compte pas ses heures pour débugger le projet, qu’il se défonce, râle et s’épuise pour tenir les délais. Plus objectivement, dans la feuille Excel du manager, Bob aura corrigé plus de bugs qu’Alice.

Bob est prudent, il sait qu’une régression signifie une retenue sur salaire. Il veille donc à tester ses corrections de bugs, en pratiquant un Defect Testing zélé. Tout l’y incite et c’est une bonne chose, mais n’aurait-il pas mieux valu que ces bugs n’aient jamais existé ?

En fin de mois, Bob aura un meilleur bonus qu’Alice. Pire : Bob aura une meilleure image auprès des managers : plus présent, plus impliqué, plus solidaire qu’Alice ! Chez Alice, la frustration monte lentement. Après plusieurs mois, Alice sera excédée. Elle sera engagée sur la pente du ressentiment et mènera les actions suivantes :

  1. Tirer Bob vers le haut. Supposons Alice bienveillante. Elle va expliquer à Bob l’intérêt d’écrire un code de qualité. Or, même s’il est de bonne volonté, Bob n’a pas intérêt à changer. Ne plus générer de bugs, c’est baisser sa rémunération et perdre les faveurs du management ! Alice va donc commencer à …
  2. Haïr le management. Alice garde de bons liens avec Bob, voire essaye de s’en faire un allié. Elle tente de plaider sa cause auprès de la direction, mais la différence subjective d’image ne jouera pas en sa faveur. Elle passera pour la mauvaise élève qui tente de déplacer les poteaux de but, voire pour la collègue pétrie de jalousie. Bob n’a aucun intérêt à aller au delà de l’empathie passive. Alice finira par lui reprocher et en viendra à …
  3. Haïr Bob personnellement. Il ne mérite pas cet argent, il doit payer autrement. Bob ayant les faveurs de la direction, il est difficile de le dénigrer directement. Si elle n’a pas déjà démissionné, Alice baissera ses standards de qualité, afin de que Bob ne bénéficie plus de SON travail. Il veut travailler dans une soue ? Grand bien lui en fasse.

Pour les besoin de la narration supposons qu’Alice n’ait pas démissionné. Elle est devenue un Bob. Son comportement s’est d’abord ajusté par jalousie, pour emmerder Bob. Au fil des mois, sa rémunération augmentant avec l’approbation du management, Alice finira par oublier sa situation initiale. Elle est devenue une meilleure joueuse, considérant les règles en place.

5 ans plus tard, les référents techniques, les managers et les Lead Dev peuvent êtres des Alice ou des Bob, cela importe peu, de différents au départ ils sont devenus totalement interchangeables. Les objectifs peuvent même avoir disparu entre temps, la culture d’entreprise a intégré des pratiques qu’il sera très difficile de changer.

Dans le management des équipes comme dans la mise en orbite de satellites, un petit changement de trajectoire, indolore au départ, peut avoir des conséquences catastrophiques à l’arrivée.

Que faire ? Essai stratégique.

Que faire ? (Lénine) — Wikipédia

J’ai vécu ce qu’a subi Alice, mais je suis parti avant que ma haine du jeu ne se change en haine des joueurs. J’ai pris du recul et élaboré une réponse stratégique à ce problème.

Cette situation est une variante du Théorème du Singe, que l’on retrouve autant en entreprise qu’en politique ou dans les schémas d’usage des technologies. En faisant preuve d’empirisme organisateur, j’ai trouvé à ce jour trois issues pour quiconque refuse de finir comme Alice :

  • La contre-culture. C’est la voie majoritaire actuellement, avec le mouvement de l’artisanat du logiciel (software craftmanship). Devenir indépendant, travailler avec des clients « qui ont compris » (slogan de l’entreprise Arpinum), se fréquenter entre artisans comme sur Okiwi. L’idée est de créer un marché du code de qualité, cohabitant à côté du marché du code de masse.
  • L’entrisme dans le management. En France depuis Vichy, c’est le management qui amorce les changements, la base doit se contenter de suivre. Dans cette voie, le développeur accepte de jouer le jeu, pour mieux injecter son venin chez les grands comptes. Il entre par la porte de la formation, du conseil, du coaching, des RH, bref des fonctions transverses. L’objectif de cette stratégie est de changer les pratiques « par le haut » chez les grands comptes, en espérant les faire basculer et entraîner par mimétisme l’ensemble du marché.
  • Le rapport de forces. Dans ce scénario, Alice tient bon. Elle refuse de céder à la haine de Bob, cède au management sur l’accessoire, mais ne transige pas sur ce qui est fondamental : la qualité. Pour cela il faut une grande détermination et une bonne connaissance du Code du Travail. Le but est d’occuper, de durer, de convertir et de peser. C’est le modèle syndical. S’accrocher, tenir et finir par montrer que l’on a raison, à l’usure.

Je n’affirme pas la supériorité d’une stratégie par rapport à un autre. Je pense même que seul un mélange des trois permettra le basculement vers une culture de la qualité dans le logiciel. Mon propos est d’ouvrir des portes. Trop d’articles se contentent de constater les dégâts de la sous-qualité logicielle, en expliquent les causes et les remèdes sur un plan purement opérationnel et technique. Mon propos est de nature stratégique : Comment faire pour en finir avec les Louvois, les Chorus ou les ONP.

Cet article est le premier d’une tétralogie. Dans les mois qui viennent, je vais détailler chacune de ces pistes, mettant en évidence les avantages et les défauts de chacune. Plus important à mon sens, je souhaite relier chacune de ces stratégies avec des types de personnalités, afin d’orienter au mieux ceux qui veulent que les choses changent dans notre profession.

Enzo Sandré

Catégories
Non classé

Emprisonnons les mauvais développeurs

 Dans toute profession, on peut voir le travailleur de deux manières. Soit on le considère comme un ouvrier, simple paire de bras reliée au cerveau de son chef. Soit on le considère comme un artisan, humain constitué d’un encéphale fonctionnel relié à une paire de bras.

Ce débat peut paraître lointain, mais quand on pose cette question à propos d’une profession qui dirige le monde, elle prend une gravité certaine. La condamnation vendredi 25 août du développeur James Liang, à 40 mois de prison et 200 000€ d’amende pour son rôle dans l’affaire Volkswagen le montre.

Soit on considère le développeur comme un exécutant, donc irresponsable de ce que son donneur d’ordre lui demande.

Soit on le considère comme un artisan, responsable de ses actes et des effets des monstres qu’il créé.

Préférez-vous confier votre pacemaker, votre voiture autonome et votre centrale nucléaire à des professionnels du développement ou à des esclaves du capital ? Les premiers obéissent à des règles de l’art ainsi qu’à une éthique. Les seconds obéissent aveuglément à leur chef, qui n’y connaît rien et ne jure que par la rentabilité.

La conséquence directe de ce choix est le droit ou non des développeurs à se diriger eux-mêmes. Un ouvrier n’a aucune compétence propre, il est une paire de bras. Il n’a pas de devoirs, donc pas de droits non plus. Son rôle social est au mieux celui d’un syndiqué se battant pour des conditions de travail décentes.

Un artisan est un professionnel qui a le devoir de produire un travail bon et utile à la société, il doit donc exiger des droits allant dans ce sens. Le premier est celui d’être protégé par des normes que nul ne peut ignorer : les règles de l’art. Le second est celui d’être jugé en première instance par ses pairs, sur la base desdites normes. Le troisième est celui d’être défendu et conseillé par les maîtres de sa profession, y compris face à son donneur d’ordres lorsque l’éthique professionnelle est en jeu.

Si notre ami James Liang avait eu un corps de métier pour le défendre face aux exigences frauduleuses de ses supérieurs, aurait-il accepté de trafiquer les véhicules ? Isolé, le lanceur d’alertes risque le licenciement, la ruine et la prison. Les règles de l’art opposables protègent le professionnel, elles ne sont pas un carcan. Le but premier d’un corps de métier est la diffusion de celles-ci afin que nul ne puisse les ignorer.

Une société qui interdit les ordres professionnels n’a pas le droit de se plaindre des méfaits de travailleurs toxiques. Au pire malhonnêtes, au mieux sans défense face aux exigences de leur hiérarchie, ils sont la conséquence de la recherche du profit à tout prix. Les premiers doivent être jetés en prison, les seconds doivent être défendus et accompagnés.

Derrière la question de la responsabilité des travailleurs devant leurs actes, deux visions de la société s’opposent : la première bâillonne l’éthique au nom de la rentabilité, pavant la voix à une véritable voyoucratie du capital. La seconde jugule les pratiques néfastes au nom de l’éthique et du bien commun. Avènement de corporations servant le bien commun, ou triomphe du Capital. Aucune autre alternative n’existe.

Enzo Sandré

Catégories
AF2000

Décoder les développeurs : enquête sur une profession à l’avant-garde

Celui qui raisonne comme au XXème siècle ne peut pas comprendre les développeurs. Ils sont les enfants terribles de la post-modernité, dans toutes ses contradictions : symboles du progrès technologique guidés par une conscience artisanale ; cols blancs à la mentalité ouvrière bien trempée ; libertaires contractualistes rêvant de communautés de métier ; geeks technophiles sévèrement critiques de la machine.

Cette profession si particulière (que j’exerce moi-même avec beaucoup de fierté) annonce-t-elle un nouvel âge du travailleur qualifié ? Elle pourrait, comme le dit l’auteur « dessiner les contours d’organisations différentes, qui valorisent l’autonomie, la collaboration et l’énergie créative » et estomper le brouillard du taylorisme. Pour comprendre comment, il est incontournable de se pencher sur les caractéristiques du métier de développeur.

Le col ciel : un artisan de l’information

Le rôle d’un développeur est de programmer des logiciels en écrivant des instructions exécutées par la machine : le code. Le travail de développeur est hybride entre la profession intellectuelle et l’artisanat. L’auteur utilise l’expression « cols ciel », jonction entre les « cols bleus » et les « cols blancs » pour les désigner.

Comme tout artisan, le développeur ne peut pas être un individualiste. Même celui qui travaille seul a besoin de ses pairs. De nombreuses communautés en ligne ou physiques permettent au développeur de se former, de résoudre des problèmes rencontrés par d’autres ou de partager du code, en dehors de tout cadre marchand. La plupart des logiciels qui forment l’écosystème informatique aujourd’hui sont libres et aucun développeur ne pourrait travailler en autarcie sans programmer des années pour afficher la moindre image. En un sens, tout développeur est un héritier, devant tout à ses prédécesseurs.

Celui qui travaille en équipe est étroitement lié à ses coéquipiers, car tous modèlent en même temps le produit. Tout comme un orchestre, une équipe doit d’abord apprendre à travailler ensemble et le moindre changement humain est handicapant, le temps d’apprendre à travailler avec le nouveau venu. La taille d’une équipe n’indique en rien sa productivité : si un développeur peut faire un programme en neuf mois, neuf développeurs n’arriveront pas forcément à faire un programme en un mois, sauf s’ils ont appris à œuvrer ensemble.

Les rapports des développeurs avec les managers sont souvent conflictuels : les deux mondes ne se comprennent pas. Des pratiques comme la programmation en binôme, la revue de code mutuelle, le développement piloté par les tests et les entraînements sur du code improductif sont courantes dans les équipes de développement mais constituent de vraies hérésies pour un successeur de Taylor. Plus frustrant : les managers ont rarement le dernier mot face aux développeurs. Le code peut être soumis à des mesures objectives de qualité et de fonctionnalité. Comme le menuisier peut renvoyer son chef à la mesure de l’équerre et du fil à plomb, le développeur peut prouver la conformité du programme aux spécifications par des tests.

Chaque morceau de code produit doit pouvoir être relu et édité facilement, il en va de la productivité de l’équipe. « Laisse le code plus propre que tu ne l’as trouvé » est une des devises des développeurs. Etonnamment, ceux qui suivent cette règle finissent par l’intérioriser en une sorte de conscience ouvrière : le travail bien fait devient un primat.

Une profession en devenir

L’auteur dresse un portrait particulièrement élogieux des développeurs. Je dois dire que je m’y retrouve presque intégralement, me définissant moi-même comme « artisan-développeur ». Hélas l’auteur laisse dans l’ombre la majorité de la profession, les « analystes-programmeurs » et autres « ingénieurs développement ». L’analyste-programmeur pratique le même métier que le développeur, mais avec une mentalité différente : il privilégie un logiciel rapidement fonctionnel à un travail léché et préfère tout planifier à l’avance dans d’énormes cahiers des charges. Alors que le développeur n’a pas d’autre plan de carrière que de devenir un maître, l’analyste programmeur ne rêve que d’être un chef de projet, puis de suivre le parcours balisé du management technique d’entreprise. Les deux composantes de la profession se méprisent mutuellement : les développeurs voient les programmeurs comme des professionnels peu consciencieux, ceux-ci rétorquent en accusant les développeurs d’utopisme et de caprice d’enfant gâté. Il est intéressant de voir qu’à technique égale, la culture est déterminante dans l’usage que l’on en fait.

L’auteur a pris le parti de décrire une avant-garde artisanale de la profession, appelée sans nul doute à grandir et à s’organiser dans les prochaines années. Les déboires de monstres logiciels comme Louvois (logiciel de paiement des soldes de l’armée française) donnent des arguments de choc aux développeurs. Les sessions d’entraînement de type « coding dojo », le désormais célèbre Agile Tour et l’Ordre des Développeurs naissant sont autant de projets extrêmement stimulants, annonciateurs d’un nouvel âge du travailleur qualifié.

Enzo SANDRE
Artisan-développeur

Références

Décoder les développeurs – Un livre sur une profession à l’avant-garde

Benjamin Tainturier – Préface d’Emmanuelle Duez – The Boson Project – Enquête sur une profession à l’avant-garde 138 pages – 19 € – G 56739

Livre gracieusement offert par l’éditeur Eyrolles.

Photo d’entête : atelier logiciel Arpinum

Catégories
Non classé

Agilité et maurassisme

Il est des choses comme ça que l’on croirait très éloignées, impossibles à rapprocher mais qui pourtant présentent des aspects communs que l’on ne remarque souvent que par hasard, celui d’une lecture, d’une rencontre d’un événement.Ici deux courants de pensées que j’aimerais rapprocher :

  • L’Agilité, réponse du bon sens à la rigidité et la lourdeur des idéologies industrielles regroupées sous l’appellation d’Organisation « Scientifique » du Travail (O.S.T) : Néo-Taylorisme, Juridisme, Procédurisme …
  • Le Maurassisme, ou positivisme politique en réponse aux idéologies politique issues de la révolution libérale : Marxisme, Libéralisme, Nazisme …

Premier constat : les deux sont des réponses à des concepts apparus autour de la révolution industrielle ou bien grâce à elle.

Second constat : les deux se basent sur l’étude rationnelle des faits pour tirer des conclusions, ce sont des contre-idéologies.

Troisième constat : les deux constatent la faillibilité de l’humain et plutôt que de la nier, font avec et bâtissent des systèmes résistants.

Quatrième constat : les deux prônent des systèmes basés sur les compétences de chaque acteur et la liberté absolue d’exercer un rôle bien précis plutôt que de vouloir des rôles larges de touche-à-tout bon-à-rien.

Cinquième constat : les deux voient la réorganisation interne du système comme un moyen d’adaptation.

Sixième constat : les deux voient d’un bon œil l’auto-organisation des acteurs.

Septième constat : les deux ont pour but de servir le plus efficacement le commanditaire.

Les deux ne servent pas les mêmes buts, mais je trouvais intéressant ce rapprochement.