Arpinum

Ou comment intéresser un programmeur à la programmation propre

Je rebondis sur le billet d’Olivier, car il fait parfaitement écho à certaines de mes interrogations de ces derniers mois. Cet article représente mes réflexions du moment, pas une vérité transcendantale et universelle. Je vais m’appuyer sur mes vagues connaissances en plus des biais cognitifs et des motivations, autant dire clairement que je suis à peine un apprenti sorcier dans ces domaines. Allez c’est parti.

Le constat

C’est un peu comme s’il existait les développeurs intéressés par les pratiques d’ingénierie d’un côté, et les autres de l’autre côté. «L’agile tour c’est pas pour les développeurs», «TDD c’est pas la vraie vie», voilà des remarques qui me brisent un peu le cœur mais que j’entends très régulièrement. Pourtant, écrire du bon code, ce n’est pas une lubie d’extrêmistes qui aiment bâtir des cathédrales, c’est vital pour un certain nombre de raisons.

En gros, mes conférences, que je considère comme étant pour développeurs, vu que j’en suis un, sont assez souvent acceptées dans le monde des conférences agiles, mais pour le moment, le succès est mitigé dans les conférences «100%» développeurs : JUGs, Devoxx, etc. D’un côté, on va me dire qu’un agile tour c’est pas pour les développeurs, et d’un autre côté on va me dire que la manière dont je code en fait 7 heures par jour ne marche pas dans «la vraie vie».

Un modèle d’explication

Qui est le développeur de 2014 ? En inspectant ma propre carrière, j’en suis venu à me fabriquer une sorte de petit modèle d’explication. D’explication de quoi ? Et bien essentiellement de ce qui fait qu’en début de carrière, les conférences qui me tiennent à cœur aujourd’hui ne m’intéressaient pas.

Les deux phases de la vie d’un programmeur

Est-ce que vous vous souvenez de votre première expérience de conduite ? En ce qui me concerne, les débuts étaient assez délicats. Pourquoi ? Car les mécanismes les plus élémentaires de la conduite me demandaient un acte conscient : changer une vitesse, garder ma trajectoire, faire attention à mon environnement, etc. Le souci du coup, c’est que mes réflexes n’étaient pas optimum, car une grande partie de mon attention était accaparée par ces détails. Avec le temps, ces mécanismes sont devenus des automatismes, qui ne me demandaient plus une concentration consciente. C’est ce qui entraine parfois ce fameux effet : « ah je suis arrivé, mais je n’ai aucun souvenir de la route.» Il parait que c’est le mécanisme standard d’apprentissage de notre cerveau : pour libérer du « temps de traitement conscient », notre cerveau va faire descendre en inconscient tout ce qu’il peut. Par exemple, reconnaître un visage ne vous demande pas d’effort (normalement), manipuler votre main ne vous demande pas d’effort, etc.

Quand je me rappelle mes débuts en programmation, je trouve que ce modèle s’applique bien : écrire un if me demandait un effort conscient, compiler me demandait un effort conscient, etc. C’est que j’appellerais la phase 1. Elle a duré pas mal de temps chez moi. Du moment où je me suis mis à programmer vers 14 15 ans, à la fin de mes 5 premières années d’expérience (à peu prêt). Du coup, mon cerveau étant intégralement pris par le «il faut que ça fonctionne», il restait peu de place pour le «il faut le faire bien». Ce qui caractérise à mes yeux également cette phase , c’est que si le Jean-Baptiste d’aujourd’hui allait s’adresser au Jean-Baptiste de cette époque, ils ne se comprendraient absolument pas.

Que se passe-t-il en phase 2 ? Etant donné que la technique est à peu près maîtrisée, le cerveau est libéré pour d’autres tâches. En programmation, cela veut dire que notre cerveau est libéré pour réfléchir au pourquoi nous faisons ce que nous faisons : quel est le problème du client ? Quelle est la meilleure manière d’atteindre cet objectif ? En d’autres termes, il devient possible de se poser la question «comment le faire bien ?».

De la technique à apprendre

De quoi était fait mon travail pendant cette phase 1 ? De programmation par coincidence. C’est à dire, sans citer cette grande boîte de e-commerce française chez qui j’étais, mon quotidien consistait à écrire des procédures stockées (beaucoup), et l’ASP qui appelait ces procédures, et générer du XML mangé par des XSLT. Je ne sais pas si vous sentez le concept, mais dans une telle approche, on ne se pose pas vraiment la question de coder proprement, du moins pas dans mes termes actuelles. Je me posais la question de commenter ou pas, de comment structurer mes 6000 lignes (sic) de prostock pour que je m’y retrouve, mais si vous me parliez de principes SOLID, de design patterns, d’architecture hexagonale, de TDD, je vous aurais taxé « d’architecte » ou de développeur non pragmatique, il n’y avait juste pas de lien entre mon quotidien et ces pratiques. En revanche, je suis allé aux Tech Days, je voulais qu’on me présente les nouveautés de SQL Server, savoir ce que ça allait changer à mon quotidien

Une illusion à perdre

Le souci dans tout ça, c’est que chaque jour je ne devenais pas meilleur programmeur, je devenais juste plus fort à gérer cette manière de faire. Or, tout système a une vélocité naturelle qu’il est impossible de dépasser, et la vélocité de celui-ci était très limitée.

Pourtant à l’époque, je me pensais pas mauvais. J’avais même eu cette grandre phrase lors d’une soirée : «honnêtement je ne vois pas ce qu’il me reste à apprendre». Je pense que trois éléments m’empéchaient de devenir meilleur : 

• Je voulais avoir une sensation de maîtriser mon travail, une des trois motivations intrinsèques¹
• La dissonnance cognitive, rien que ça ²
• L’effet Dunning-Kruger ³

Ok comment j’assemble ces trois éléments ? L’effet Dunning Kruger en gros me dit qu’à l’époque, la quantité de choses que je ne savais pas m’empêchait d’évaluer correctement la qualité de mon travail. Je le jugeais correct exclusivement à la lumière de mes compétences de l’époque, qui étaient trèèèès faibles. (je vous rassure, il me reste encore beaucoup de chemin à parcourir). A côté de ça, mon envie de maîtriser ce que je faisais ne me donnait pas envie d’entendre qu’en fait, je ne savais vraiment rien. Du coup, quand par un biais x ou y j’entendais une remise en question, cela créait cette désagréable dissonance cognitive : je souhaite maîtriser mieux mon travail, mais la piste que l’on me propose a l’air de demander trop de temps et d’efforts, ou bien me met mal à l’aise tant elle a l’air de montrer qu’il me reste un gouffre à franchir. Du coup, comme le renard, j’ai décidé que ces raisins ne valaient pas la peine d’être mangés. Le fameux «TDD ça ne marchera pas dans mon quotidien», ou mon fameux à l’époque «les design patterns ça sert à rien, ici on est pragmatique on fait ce qui marche».

Il est tout à fait possible de rester bloquer éternellement dans cette phase de cette manière, à répéter la même année chaque année, à avoir l’impression d’être bon car on a atteint la vélocité maximum de ce système. Il faut réussir à perdre cette illusion : la seule manière d’apprendre, c’est d’accepter que l’on ne sait rien, et de laisser l’égo au vestiaire.

Cette étape est nécessaire

Je peux paraître très négatif, mais cette étape est malgré tout nécessaire. La programmation demande de maîtriser ou d’apprendre beaucoup de concepts. Comment réfléchir à écrire un bon test, si le simple fait d’écrire un for accapare 90% de notre cerveau ? Comment réfléchir aux principes SOLID alors qu’on ne manipule pas des classes au quotidien, ou qu’on en fait apparaître par hasard ? Comment prendre des risques pour apprendre à faire mieux, si j’ai la pression au quotidien ? Depuis 3 ans que j’enseigne, je peux effectivement vous faire ce retour : tenter d’enseigner TDD à quelqu’un qui commence juste la programmation, ça ne marche absolument pas. Pour démarrer, il faut donc cette phase d’expérimentation, de dialogue simple entre le code et le résultat visuel. Ce n’est pas un hasard si j’ai appris la programmation avec VB, le résultat visuel était là rapidement. Ce n’est pas un hasard si je me suis mis à PHP pendant ma 1ère S : je tapais quelques lignes, je faisais F5 dans le navigateur et pouf magiquement la page avait un nouveau comportement. Ce dialogue code / visuel, cet émerveillement d’avoir l’impression de maîtriser sa machine, c’est vraiment la clef de la création de ma passion.

Le déclencheur

Il n’y a pas vraiment de magie, ce qui m’a fait quitter cette phase c’est l’accumulation de plusieurs facteurs :

• démission de mon poste, poussé par l’envie de découvrir autre chose
• la rencontre avec quelqu’un déjà plus avancé sur le chemin de l’amélioration continue
• l’émerveillement lié à la mise en place de TDD
• la lecture de DDD et eXtreme Programming explained

A partir de là, mon quotidien n’a plus consisté à assembler des bouts techniques de bric et de broc, mais à tenter de faire bien les choses. Le « ça fonctionne » est devenu le strict miminum de mon travail, et non plus l’objectif. Le «d’abord faite le marcher, puis faite le marcher bien, puis faite le marcher vite» est devenu mon mantra. A partir de là, une conférence me présentant un outil, me présentant un framework, a clairement commencé à m’ennuyer. Je n’ai plus cherché de missions pour apprendre une nouvelle technologie, mais pour avoir la possibilité de faire mieux. Nous avons créé Tiron dans cet objectif : apprendre à faire mieux, sans contrainte, et c’est maintenant le crédo d’Arpinum. Avant d’être une boîte qui nous fait vivre, Arpinum est avant tout une boîte qui nous fait apprendre.

Revenons à la question

Donc, nous avons vu mon début d’explication sur pourquoi il est difficile de parler à la majorité des développeurs. Si cette hypothèse détient une partie de vérité (tous les modèles sont faux, certains sont utiles), nous pouvons alors tenter de fabriquer un discours qui leur parle. J’ai le sentiment qu’une majorité des développeurs intéressés par ces conférences sont quelque part coincés entre les deux phases: ils veulent faire mieux, sinon ils ne prendraient pas de leur temps pour venir. Ils sont passionnés également. Mais il est encore difficile de parler de TDD, de refactoring, car leur quotidien, souvent dans des boîtes oldshool, avec architecture imposée, 0 test, etc : ces sujets ne résonnent pas avec les sujets de qualité de code. Ce que m’a montré mes quelques années d’enseignement, c’est qu’un module de 20h avec des 4ème année suffit à « convertir » au moins une certaine fraction des élèves à ces approches. Mais le cours est « forcé », comment attirer de gens libres de leur temps dans un module de 20h parlant de TDD?

La stratégie Gageot

Je ne sais pas si vous le connaissez, mais David Gageot est un développeur à suivre : ses conférences sont excellentes. Ses sessions de live coding sont purement des démonstrations de refactoring, de tests bien fait, etc. Son Github est rempli de pépites de code, bref, il remplit parfaitement mes critères d’un excellent développeur. Pourtant, si vous prenez le titre de cette session vous notez l’absence de mots clefs « agiles » . Cependant, cette présentation consiste à faire le Kata Gilded Rose, en appliquant la technique du Golden master, tout en maîtrisant à la perfection les outils de refactoring de son IDE. Cette session a eu le grand succès qu’elle mérite, je l’ai vu au Bordeaux JUG, et le public était conquis. Ce public qui massivement ne vient pas à un Agile Tour, ne vient pas à une session TDD ou refactoring, est non seulement venu, mais a adoré. La session se serait nommée « démonstration de refactoring de code legacy par la Kata Gilded Rose », aurait-elle eu le même succès ? Est-ce donc ça la technique ? Dissimuler notre contenu derrière des buzz words ? Cloud, Legacy, etc ? Nous avons mené une petite expérience à Arpinum. Grâce à Guillaume Saint-Etienne, nous avons monté une formation parlant de l’architecture agile présentée lors de ma session « Le mythe du framework agile »⁴. Pourtant, cette formation s’appelle officiellement « Développement Web en Java ». Nous avons proposé cette formation dans les milieux très friands de formations techniques : succès. Il y a deux ans, nous avons tenté une formation TDD avec les mêmes personnes : aucune inscription.

Start with why

Le pourquoi est toujours massivement important dans la motivation de quelqu’un a participé à une entreprise, une formation, etc. Nous avons vendu le pourquoi de nos conférences seulement sur ce postulat : « le code propre, c’est important ». Ce « pourquoi » parle dans un Agile Tour (et encore), mais pas dans une conférence plus technique j’ai l’impression. Nous devons donc mettre le pourquoi du côté de la technique dans une conférence technique : le cloud, le web, l’architecture, etc. TDD, les principes SOLID, ne peuvent pas être le but de la session, mais le comment. Le mythe du framework agile a eu des échos dans des milieux moins agiles qu’à mon habitude, car mon « pourquoi » j’ai l’impression ne se situait pas sur les pratiques agiles en elles mêmes, mais sur un terrain plus technique : les frameworks.

Pour conclure

Voilà, cette analyse vaut ce qu’elle vaut, mais elle a le mérite au moins de proposer un modèle qui s’applique à ma carrière. Comme je n’ai pas l’impression d’être si particulier que ça, peut-être aidera-t-elle d’autres développeurs.