Avant-propos

Cet article est une retranscription de la conférence que j’ai donnée lors de l’agile tour de Montpellier le 13 octobre 2015. Pour mieux suivre, je vous conseille de regarder en parallèle les slides de la conférence.

A propos de moi

Je m’appelle Gilles et je suis artisan développeur.
Dans cet article, je vais vous parler de moi, de mon métier et de ma famille.

Plus particulièrement de l’évolution de la perception de mon métier et comment le métier de mon père et de mon grand-père m’ont aidé à devenir un développeur plus heureux.

La mode du software craftmanship

Il n’y a pas si longtemps, j’ai changé de poste et quand j’ai fait mon CV, j’ai mis que j’étais artisan développeur.

Il y a quelques années, j’ai vu débarquer cette mode lors de conférences, dans des articles sur Software Craftsmanship.

J’ai trouvé ça sympa comme titre : artisan développeur ! Un contraste entre du moderne et du traditionnel. Et moi comme un mouton, j’ai trouvé ça cool et je me suis dépêché de modifier mon profil twitter.

Je trouvais ça d’autant plus cool que je suis issu d’une famille d’artisans : mon père artisan maçon, mon grand-père artisan maçon et artiste, mon arrière-grand-père plâtrier…

Un jour, ma femme a regardé mon twitter. Et bien sûr, elle m’a demandé pourquoi je mettais ce titre, quel est le rapport entre mon métier et les artisans ? Entre un maçon, un électricien, un façadier et moi ?

Sur le coup, je n’ai pas su répondre. La réalité c’est, qu’à l’époque, je n’avais pas compris le sens de ce titre…

Introspection

Dans ma jeunesse, chaque été, j’ai travaillé avec mon père sur les chantiers. Façade, toiture, carrelage… J’ai fait un peu de tout.

Par exemple j’ai travaillé sur la façade de l’Impérator à Nîmes.

Je me suis donc mis à chercher les liens, les corrélations, les ressemblances qu’il peut y avoir entre moi développeur, et l’artisan maçon qui vient refaire ma toiture.

En passant chez mon grand-père, je suis un jour tombé par hasard sur ce document.

C’est un ancien document qu’il donnait lorsqu’on lui demandait ses références ou ses compétences. Comment présente-t-il ça ? Des photos de chantiers, en expliquant ce qu’il a fait !
J’adore. Pourquoi j’adore ? Parce qu’on devrait tous faire ça ! Surtout nous, les développeurs.

C’est très important pour moi : le savoir-faire.

Montrer notre savoir faire plutôt que nos diplômes, ça c’est intéressant ! Votre meilleur CV : c’est votre compte Github ! Faites de l’open-source, montrez votre travail, faites un site et écrivez des articles technique. Votre point fort ce n’est pas votre formation, c’est votre savoir faire, alors montrez-le !

En fait, ce document, c’est le compte Github de mon grand-père.

Savoir-faire

Je dis souvent que si le jeune va plus vite, l’ancien connait la route. En informatique ils appellent ça l’expérience, moi je préfère parler de savoir-faire. La réalité, c’est que l’on n’apprend pas à coder à l’école, on apprend à coder sur le terrain.

A l’école on voit quelques bases de développement, les notions simple d’algorithmique, et on ne voit pas comment gérer un site avec un trafic de millions de visiteurs par mois, on ne voit pas comment reprendre un projet mal codé, sans tests et sans documentation, on ne voit pas les principes de la programmation “moderne” comme l’injection de dépendances, Clean code ou les principes SOLID (en tout cas, moi je ne l’ai jamais vu… et j’espère que l’on en parle maintenant !).

Comment cela se passe chez les artisans ? On ne parle pas vraiment de formations ou d’études, on parle d’apprentissage, la différence c’est que l’on apprend par la pratique.

On peut t’expliquer pendant des heures comment monter un mur ou comment poser du carrelage, tant que tu ne l’as pas fait, tu ne sais pas faire ! Quel est le meilleur moyen d’apprendre à faire un site internet, une application mobile ? Et bien c’est en le faisant, se trompant, refaisant, c’est là que l’on va acquérir le savoir-faire. Et encore mieux, de le faire avec quelqu’un qui sait faire, une personne pour te montrer, t’expliquer, te faire apprendre de tes erreurs.

De la pierre sèche

Je vais vous parler un peu de mon grand-père. Mon grand-père est un spécialiste, un expert comme on dit, de la pierre sèche. Il construit différents ouvrages : des murs, des escaliers, des capitelles, des norias… Je m’y suis essayé l’été dernier et je lui ai demandé de m’apprendre en construisant un simple mur de clôture.

Pendant cet apprentissage, j’ai été impressionné par une chose en particulier : quand mon grand-père travaille, tout parait simple.

Il regarde son mur, il prend une pierre, on dirait presque qu’il la prend au hasard, il la pose, la cale, la teste. De la première à la dernière pierre, chaque pierre parait simple à poser.

Alors que moi… les premières pierres, ça va… Mais dès que ça commence à monter, ça devient de plus en plus compliqué… et de plus en plus bancal…

Mon grand-père a regardé mon mur et m’a expliqué que si c’était de plus en plus dur, c’est que je n’avais pas respecté quelques bonnes pratiques de construction : je n’ai pas mis de boutisses, j’ai fait des coups de sabres et que j’ai posé une damasse, une pile d’assiettes…

Moi, ça m’a fait penser à autre chose: sa boutisse, c’est comme notre Factory, sa damasse c’est comme notre Singleton… En fait, il y a des design patterns dans la construction d’un mur ! Et il faut les utiliser pour que le mur soit solide.

Lorsque j’ai posé la damasse, j’ai eu l’impression de gagner beaucoup de temps. Mais une fois que j’ai commencé à poser des pierres dessus, ça s’est compliqué, j’avais du mal à les faire tenir car la damasse ne me donnait pas une assise solide. J’ai fini par l’enlever… et donc à enlever toutes les pierres d’au-dessus et d’à côté. J’avais du mauvais code dans mon mur qui m’handicapait et m’empêchait de progresser correctement. Du coup, j’ai refactoré mon mur.

Si pour mon grand-père la dernière pierre est aussi facile à poser, c’est qu’il a soigné son travail dès le début. Il a respecté les patterns de construction. Même les pierres posées à l’intérieur, qui ne se voient pas étaient posées avec soin, car elles sont aussi importantes que celles que l’on voit. L’attention que mon grand-père porte à chaque détail est impressionnante.

A propos de la simplicité

J’ai récemment travaillé sur un projet de synchronisation entre une base de données et une API rest. Le chef de projet me soutenait qu’il n’y avait rien à faire, que ça prendrait 2 jours au maximum… Un chef de projet quoi… Bien sûr tout ça en .Net, une technologie que je maîtrisais assez peu, sur une base de données inconnue et bien sûr pas très propre, avec aucune contrainte d’intégrité, des données dupliquées…

Bref, une belle merde…

5 jours plus tard, je rends le projet fini et fonctionnel. Je montre le code au chef de projet. Sa réaction m’a vraiment surpris : il m’a dit “Et ben tu vois, c’était simple, ton code est super simple, y’avait pas grand chose à faire finalement”.

J’ai dit “Merci”.

Parce que j’ai repensé à mon grand père, si mon code a l’air simple, c’est qu’il y a du travail derrière. C’est le savoir faire du développeur qui rend les choses simples !

Ce projet, il a été transféré à un stagiaire. On lui a demandé d’ajouter des logs. Et bizarrement le projet est devenu complexe. Pour des logs ? Pourquoi ?

Lorsque on ajoute un log, voici le code qu’il a ajouté à chaque fois :

if (Configuration.LOG_LEVEL == "prod") {
   this.logger.logSimple("...");
}
if (Configuration.LOG_LEVEL == "dev") {
    this.logger.logSimple("..."));
    this.logger.logFull("...");
}

Et ça, plusieurs fois par classe, plusieurs fois même par fonction !

Pourquoi c’est moche ?
Parce qu’il n’a pas respecté les patterns ?
Peut-être parce qu’il n’avait pas de mentor ?
Peut-être qu’il n’a pas appris à le faire ?
Peut-être qu’il ne s’était pas encore planté en le faisant ?

La simplicité est la conséquence d’une architecture bien construite.

Quand je travaille à l’amélioration d’une classe, d’un projet, je pense souvent à cette phrase de Saint-Exupéry : “La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer.” J’essaie au maximum de garder ça en tête. Si une fonction, une classe me paraît complexe, je me demande toujours : qu’est-ce que je peux enlever ?

Je dis d’ailleurs souvent que le code me paraît complexe. Dans le code, beaucoup de choses sont du ressenti, du sentiment. À mon sens, le meilleur indicateur d’un code mal écrit, c’est mes tripes.
Ça se sent quand un code est mal écrit, c’est pour cela qu’en Clean code on parle de code smells, d’odeurs de code. Si je vois un singleton, ça pue, je sens que quelque chose ne va pas, comme quand mon grand-père voit un coup de sabre.

De l’effort

Lors de mes différents étés passés sur les chantiers avec mon père, j’ai fait plusieurs ascenseurs. Je me souviens du premier sur lequel j’ai travaillé.

8 étages… et sans ascenseur bien sûr ! Il fallait casser une partie de l’escalier pour que l’ascenseur puisse passer au milieu. J’étais jeune, et un peu con. Mon père cassait l’escalier au dernier étage et moi je descendais les seaux de ruine…. Je monte, je remplis, je descends, je vide, je remonte, je remplis….

Au milieu, mon père a commencé à me demander une pelle, je descends et je remonte une pelle, puis un marteau… etc…

Mon père m’a rapidement arrêté et m’a sorti sa citation préférée : “Qui n’a pas de tête, a de bonnes jambes”.
Je ne réfléchissais pas, je faisais des trajets à vide, et je ne les optimisais pas. “Amène tous les outils d’un coup au lieu de les amener un par un, et ne cours pas, ça sert à rien, optimise ton temps et tes efforts. C’est un marathon, pas un sprint.”. Aujourd’hui, j’entends ça de mon scrum master.

Le développeur qui a ajouté les logs, il a de sacrées bonnes jambes. Comme il n’a pas réfléchi, il se donne du travail en plus. En réalité, un bon développeur, comme un bon maçon, il est fainéant !

En plus, en réalité, mon père cassait le haut de l’escalier pour pouvoir y fixer une poulie, qui m’a bien simplifié le travail ensuite.

De la propreté

Il y autre une chose qui me gonflait un peu à l’époque où je travaillais sur des chantiers avec mon père, et que je n’ai pas de suite compris. C’est l’obsession de mon père pour la propreté. Chaque jour, en fin de journée, on passait bien 20 minutes tous ensemble à nettoyer le chantier. Et 20 minutes à 5-6 personnes sur une journée de 8h, c’est beaucoup.

Mon père dit : “Un bon artisan rend le chantier plus propre que lorsqu’il est arrivé“.

(Si vous vous dites que vous n’avez jamais eu de bon maçon, c’est très probable. Un bon maçon, c’est comme un bon développeur, c’est rare)

Travailler dans un environnement propre, c’est agréable. Travailler dans un environnement où tout est à sa place, c’est agréable. On est moins pollué et on est plus rapide.

Surtout qu’en maçonnerie, on fait beaucoup de béton et de mortier. Nettoyer du ciment tombé par terre le jour où il a été fait, c’est facile. Deux jours après, c’est chiant. Alors une semaine après… et encore quand ce n’est pas le client qui le fait !

Finalement, je me suis rendu compte assez rapidement que ça fait gagner du temps. Nettoyer un chantier, comme nettoyer le code fait partie de la vie de l’artisan. Il n’y a rien de pire que du code mort ou mal écrit dans une application. Ça pollue le code, ça le rend complexe, et le nettoyer devient de plus en plus difficile avec le temps.

Le temps

Il y a une chose que je déteste en tant que développeur, c’est que l’on vienne me voir en me demandant : “Combien de temps il te faut pour implémenter cette fonctionnalité ?”. Je déteste répondre à cette question. Parce que s’il y a bien une chose que mon expérience m’a appris, c’est qu’il est impossible d’estimer un développement de plus de 2h de manière précise. C’est la loi de Hofstadter :

“Il faut toujours plus de temps que prévu, même en tenant compte de la Loi de Hofstadter.”

J’ai toujours pensé que c’était une chose spécifique à mon métier. J’en ai parlé avec mon père avec une conviction qu’il a rapidement ébranlée. Pour moi, lorsqu’un maçon fait un devis, il y a une grosse partie de matériaux et le temps de main d’oeuvre est facilement mesurable et estimable.

Quand je lui ai dit ça, il m’a répondu en souriant: “Tu sais Gilles, les matériaux, c’est en général 20% d’un devis. Le reste c’est de la main d’oeuvre. Pour estimer la main d’oeuvre, en général, je le fais au doigt mouillé… et je multiplie par 2”

Comme moi…

“Des fois je me trompe, des fois à mon avantage et des fois non… C’est le plus difficile. Le problème c’est qu’il y a tellement d’éléments extérieurs que tu ne peux jamais tout prévoir. Et puis, on ne fait jamais 2 fois la même chose, alors c’est difficile de sortir des règles.”

Des imprévus

Je me suis rappelé d’un chantier auquel j’ai participé il y a longtemps, je m’en rappelle bien parce que c’était particulièrement difficile.

C’était dans la cave d’un immeuble, le but était de changer la chaudière. Dans cette pièce il y avait une sorte de support en béton utilisé pour l’ancienne chaudière. Comme la nouvelle était plus grosse, il fallait le casser. Mon père avait prévu une journée à 2 (et avait donc facturé 2 jours à 2).

Je me suis retrouvé avec Ludo pour faire ça. Ludo, c’est un breton, avec l’accent, on comprend rien à ce qu’il dit, il ne fait que râler. En fait, il me fait beaucoup penser à certains de mes collègues développeurs. On arrive, sereins, avec nos marteaux piqueurs électriques et on commence à détruire ce bloc.

Au bout d’une heure, on se retrouve à taper dans quelque chose de dur, de très dur. Ceux qui avaient coulé ce bloc avaient calé de grosses pierres dedans.

Du coup, on s’est retrouvé comme des cons avec nos petits marteaux piqueurs électriques. Pas assez puissants. On appelle mon père et on décide d’aller chercher le gros marteau piqueur à air comprimé. On prend le camion, on va chercher le compresseur et le marteau piqueur, on l’installe. On commence un peu à travailler mais c’est déjà la fin de la première journée. On le désinstalle, on nettoie et la journée est finie. On n’avait pas fait le quart du travail à faire.

Finalement, on a passé 3 jours sur ce bloc de béton.

En fait, on a été confrontés à un bloc mal construit, du legacy. On ne pouvait pas prévoir ce qu’on allait trouver dedans.

D’ailleurs, je n’ai jamais entendu mon père demander à ses employés de s’engager sur une deadline.

À l’arrache

Ce genre de situation, je les vis très souvent en tant que développeur et il y a une chose qui m’étonne toujours : lorsque que l’on est confrontés à un imprévu qui peut nous faire perdre du temps, il y en a toujours un pour dire aux développeurs :

“Trouve nous une solution vite fait, fais un truc à l’arrache, t’as pas une solution plus rapide ?”.

C’est marrant, parce que, je ne me vois pas du tout dire ça à mon artisan:

“Non, mais si c’est trop compliqué de faire les fondations, n’en fais pas.”,
“Ecoute, la fenêtre, si elle ferme mal, c’est pas grave, passe en production quand même”,
“Laisse tomber les fusibles, je crois qu’EDF gère déjà la surtension”…

D’ailleurs, est-ce que vous laisseriez un artisan travailler sans tester son travail ?

J’ai participé avec mon père à la construction de murs et de toitures. Vous savez comment se monte un mur ? La pose du quéron, c’est rapide, ce qui prend du temps, et le vrai travail, c’est le test de la pose. Le fil à plomb du maçon c’est nos tests unitaires. Chaque brique du mur est testée, indépendamment, unitairement et aussi entre elles. Lorsque l’on fait une toiture, on envoie de l’eau dessus pour vérifier qu’il n’y a pas de fuite.

On teste même avant de commencer à travailler. Lorsque mon grand père commence un mur, il pose toujours un cordeau. Il permet de vérifier en permanence que chaque pierre du mur que l’on pose est alignée. On fait du TDD en quelque sorte.

Attention, ça n’empêche pas les bugs, ça les limite, mais ça ne les empêche pas. Une petite tempête et les tuiles volent, les gouttières se fissurent. Mon père passe beaucoup de temps à corriger ce genre de bugs. C’est d’ailleurs très fatigant car il passe finalement plus de temps en transport et à chercher le problème qu’à réellement réparer.

Je dis souvent que 80% de la correction d’un bug, c’est de le trouver, mon père c’est pareil… il y a d’abord le transport, puis trouver la tuile qui fuit, et finalement, la réparation, c’est rapide.
D’ailleurs, c’est marrant comme la montée en charge d’une maison peut causer des bugs. Comme le fait d’utiliser une maison pour un usage qui ne lui est pas destiné, comme lors d’une tempête, un séisme ou une inondation.
Un peu comme lorsque tu maintiens un site e-commerce et que tu es cité dans Capital.

Des outils

Mon grand-père monte des murs dans une association de jeunes en insertion. À plus de 80 ans, il faut vraiment être passionné pour faire ça. Il m’a raconté une anecdote. Une fois, il devait poser une clé mais la pierre choisie faisait plus de 100kg. C’est parfait, car le poids amènera une meilleure stabilité.

Mon grand père a dit aux jeunes : “Bon, on va mettre cette pierre là“. Tout de suite, les jeunes se sont mis à dire: “non mais c’est trop lourd, ce n’est pas possible, on va se faire mal, en plus c’est tard, c’est bon quoi…“.
Mon grand père les a laissés partir. Il a approché l’échafaudage, posé des poulies, un pont roulant et commencé à caler des cordes sous la pierre. Et il l’a montée, seul, et il l’a posée. Je ne sais pas comment il fait, mais il a utilisé son savoir-faire et toute sa fainéantise pour, à plus de 80 ans poser cette pierre.

Cela m’a rappelé cette fois où je travaillais sur un import de fichier avec un gros traitement derrière, d’abord sur un petit fichier, le script passait sans problème, le truc c’est que le fichier, finalement, il faisait des millions de lignes, et là, le serveur ne tenait plus la charge et le traitement allait prendre plusieurs jours!

Comment faire ? Découper le fichier et lancer 50 imports au lieu d’un ? Non, l’équipe était trop fainéante pour ça. J’ai préféré utiliser un pont roulant, on a monté un RabbitMq et on a traité le fichier en utilisant une queue pour un traitement asynchrone et parallélisé.
Finalement, le traitement n’a pris que quelques heures.

Je suis impressionné par le nombre d’outils différents que peut utiliser un artisan, mon grand-père les collectionne, il sillonne les brocantes pour trouver des outils toujours plus anciens et parfois bizarres.

Quand je rentre dans son atelier, j’ai l’impression d’être sur npm, composer, apt-get, gem ou pip. Des outils de toutes sortes, pour des utilisations plus ou moins spécifiques, dans des contextes différents. Une sorte de pelle recourbée pour mélanger le mortier, des marteaux de toutes les tailles…

D’ailleurs, quand j’ai travaillé sur le mur en pierre sèche, il m’a sorti un marteau avec un manche super long, un bout en pointe convexe. Pourquoi alors qu’un marteau classique suffirait ? Parce que ça évite de se baisser pour casser les pierres et que l’allonge plus longue permet de donner des coups plus secs et donc de casser plus nettement les pierres.

Mon grand-père dit toujours “un mauvais ouvrier se plaint toujours de ses outils”. En fait, chaque outil a son utilité, ses avantages, ses inconvénients et c’est à l’artisan de choisir le bon outil au bon moment.

Il a aussi une définition des outils que j’aime : “un outil c’est un objet qui modifie la matière”, les outils des développeurs, c’est php, java, python, ruby ou javascript et notre matière, ce sont les données que l’on manipule.

Des fondations

J’ai participé aussi à un autre chantier qui m’a beaucoup marqué, un chantier particulièrement difficile car il touchait toute la structure du bâtiment.

C’était un vieil immeuble de 5-6 étages dans le centre de Nîmes. Les propriétaires ont voulu y mettre un parking souterrain. Pour cela, il fallait agrandir la cave et déplacer un pilier porteur. Je ne sais pas si vous imaginez le travail de fou qu’il y avait !

Lors de l’appel d’offres, personne ne voulait le faire. Trop dangereux, risqué, trop complexe. Mon père a finalement accepté de le faire. Pendant ce chantier, je me souviens de 2 choses : son stress et de l’état de transition du sous-sol.

Pendant que l’on cassait le pilier porteur, on a été obligé de compenser en posant des étais et il y en avait tellement que l’on pouvait à peine se déplacer. On était obligé de se faufiler entre les étais pour aller casser ce pilier. Oui, refondre la structure d’un bâtiment, c’est compliqué. C’est comme modifier toute une couche d’une application, la structure de base, passer d’une UI desktop en web, passer d’une base SQL à NoSQL, ça pique.

J’ai migré plusieurs applications PHP d’une base avec un framework maison ou dépassé vers Symfony. J’ai ressenti ce stress lorsque les premières requêtes ne passent plus par le code legacy mais par le Kernel Symfony. C’était le même stress que lorsque que j’ai enlevé les étais dans ce sous sol, pour chaque étai, un par un.

C’est comme arriver sur une application avec toute une partie du code qu’aucun développeur n’ose toucher car elle est trop complexe, mal écrite, et qu’une modification peut avoir de grosses conséquences. Ça fait peur.

C’est pour moi la définition du code Legacy : c’est du code que l’on a peur de modifier.

Software craftsmanship manifesto

Toutes ces histoires pour en venir où ? Au Software craftsmanship manifesto ? C’est un manifeste signé par des professionnels comme Kent Beck ou Robert Martin qui vient comme un complément au manifeste agile :

Not only working software, but also well-crafted software
Pas seulement un logiciel qui marche, mais aussi un logiciel bien fait.
Avec des tests, au fil à plomb, au laser, avec les bons outils.

Not only responding to change, but also steadily adding value
Pas seulement répondre au changement, mais aussi ajouter régulièrement de la valeur.
Comme lorsque l’on ajoute un parking souterrain ou un ascenseur.

Not only individuals and interactions, but also a community of professionals
Pas seulement des interactions et des individus, mais aussi une communauté de professionnels.
Comme mon grand-père et son asssociation de bâtisseurs en pierres sèches.

Not only customer collaboration, but also productive partnerships
Pas seulement de la collaboration avec le client, mais aussi des partenariats productifs.

Ce qu’il faut pour moi retenir c’est qu’au-delà d’être des développeurs, nous sommes avant tout des professionnels et que si on est des professionnels, c’est que l’on a un savoir-faire.

Comme vous n’accepteriez pas que votre maçon refasse votre toiture sans vérifier si elle fuit, comme vous n’accepteriez pas que votre électricien confie votre installation à un stagiaire sans formation, confier la création d’une application, qui deviendra à terme un outil quotidien, qui va faire gagner du temps, de l’argent, qui est parfois la stratégie de toute une entreprise, ça doit être confié à des professionnels.