Comment en est-on arrivé là ?
C’est une bonne question. Intéressant de voir comment les choses dérapent, un peu au début, beaucoup ensuite !
Tout commence avec un post un brin provocateur de Kevin sur linkedin :
https://www.linkedin.com/feed/update/urn:li:activity:6943520332855054336/
Et il fait fort : les commentaires se déchaînent. Visiblement il a touché une corde sensible.
Je ne pouvais rester sans réagir : il attaque frontalement les fondements même de ce qui constitue ma pratique et de mes convictions. Ce n’est même pas tant pour mon ego, que je mets facilement de côté, que pour ne pas laisser propager un message qui me semble pervers et néfaste.
Je répond quelques mois plus tard ici :
Il y répond rapidement avec une vidéo, l’occasion de démarrer sa chaine youtube, ici :
Et il faut saluer encore une fois la performance : 1000 vues en 24h pour une chaîne naissante alors qu’il a peu d’audience, c’est joli. De là à croire que le drama y est pour quelque chose… 😏
C’est là que la machine s’emballe. D’autres influenceurs comme Pierre va apporter sa contribution au débat en essayant de réconcilier les points de vue.
https://www.linkedin.com/feed/update/urn:li:activity:7010584629527068672/
Merci Pierre. Hélas, j’ai peur que le désaccord soit si profond que nous resterons inconciliables.
C’est quoi un drama ?
Le drama, c’est un peu le nerf de la guerre de youtube. Ça dope les audiences, ça galvaude les camps. Bref, une forme de résurgence de guerre tribale. Et rien ne soude autant une communauté qu’un ennemi commun.
D’un point de vue marketing / business, c’est très bon car c’est l’occasion de passer de l’émotion en même temps que le message. Il faut juste assumer le drama.
Mais pourquoi se battre ?
Alors soyons clair : ma démarche n’est pas de convaincre Kevin. Il est perdu.
Ma démarche est de propager avec le plus de force possible un message dans lequel je crois et que Kevin a bafoué : le craft peut être un chemin épanouissant.
Je parle bien de bonheur.
Pas de techniques.
Pas juste de TDD.
Je parle d’être heureux dans son travail. Ce que Kevin balaie rapidement d’un revers de main : pour lui, le code des premiers jours sera supprimé. Ce n’est qu’une question d’argent.
Sauf que ce n’est pas aussi simple : Bien souvent le code des premiers jours dure looooooonnnnngggtemps.
Il a largement le temps d’épuiser les motivations les plus acérées, nouer les estomacs les plus costauds, broyer les cerveaux les plus brillants dans les limbes du monstre spaghetti.
Mais toute cette souffrance, Kevin la réduit à un problème financier.
Je ne suis pas d’accord.
Je parle de fierté du travail bien fait, d’estime de soi, de travailler dans un cadre satisfaisant et épanouissant.
Et c’est possible même en startup early stage : c’est très exactement dans ce contexte précis que je suis passé au TDD, seulement accompagné du livres vert que j’ai lu et relu jusqu’à l’user tellement que les pages se décollaient.
Et je pense que si nous avons pu aller aussi loin dans ce projet, vendre des licences en centaines de millions dans plus de 150 pays, avec des moyens plus que modestes, en partant de 0, c’est justement grâce à cette pratique pilier.
Si j’ai arrêté de venir au travail la boule au ventre, c’est grâce au TDD.
Si j’ai pris confiance dans mon travail au point de faire une démo devant un petit bonhomme qui pesait des milliards dans un salon international à l’autre bout du monde en étant confiant sur le fait que ça allait marcher alors qu’on jouait la vie du projet sur cette démo, c’est grâce au TDD.
Si j’ai mis la misère à Murphy ce jour là, c’est grâce au TDD.
Alors est-ce que le TDD est l’outil ultime ? Bien sûr que non. Il est d’ailleurs insuffisant pour durer : il faut aussi gagner en compétences sur le design.
C’est là que le craft intervient comme un tout cohérent, multifacette et densément riche, fait de compromis.
Alors Kévin peut se réfugier derrière des arguments du type : “non, mais ce que j’ai dit n’est valable que dans un certain contexte”. Autant le dire clairement : c’est fallacieux. Les gens ne retiennent que ce qui les arrange, et souvent hors contexte sinon c’est pas drôle.
De plus, c’est faux : mon expérience prouve au moins un contre-exemple.
Après je reconnais que ce n’est pas le contexte idéal.
Mais si tu attends le contexte idéal pour passer au craft ou au TDD, tu risques d’attendre longtemps.
Un combat perdu d’avance
Alors je sais que le combat est perdu d’avance. Kevin a les chiffres de son côté.
De mon expérience empirique tout à fait non scientifique, mais quand même étayée par plusieurs centaines de développeurs accompagnés, je dirais que 80% des devs n’ont strictement rien à faire du software craftsmanship et de ce qu’il pourrait leur apporter.
Ils codent sans trop se poser de questions et la vie est belle. Ils s’habituent souvent à une forme de médiocrité et se font une raison, jusqu’à considérer normales des choses anormales, comme par exemple les anomalies. Si tu avais un doute, c’est marqué dessus…
Venir parler de TDD ou de craft à ces gens, c’est remettre en question leur monde bien rangé et dans lequel ils sont en sécurité, même s’ils souffrent.
Quant aux 20% restants, peu passent vraiment à l’action jusqu’à remettre sérieusement en cause leur pratique. Le message de Kevin devient alors réconfortant pour justement rester dans une passivité sourde.
Ne resteront que les 20% des 20%, soit 4%, qui prendront peut-être parti.
96% VS 4%, c’est ce que j’appelle un match perdu d’avance.
Alors pourquoi continuer ?
Un peu pour le business, il faut quand même le dire.
Mais surtout pour l’honneur de défendre un point de vue qui est noble à mes yeux.
Le craft / TDD sont-ils adaptés à des startups early stage ?
C’est un peu le fond du désaccord. Lui pense que non. Moi je pense que oui.
Je pense que le TDD est une pratique intrinsèquement bénéfique pour le projet. Lui pense que ça dépend du contexte, et que le compromis coût/bénéfice n’est pas intéressant, voire dangereux, dans les phases initiales d’un projet qui a de toute façon peu de chances de survivre.
Autant le dire simplement, on est frontalement en désaccord. Cela créé une tension, de cette tension naît le débat.
J’ai enfin un adversaire à ma taille : on est clairement pas d’accord sur le sujet, on est d’accord sur nos désaccords, et l’échange reste cordial au-delà de quelques piques personnelles de bonne guerre.
Finalement, jusqu’à maintenant, les principales personnes avec lesquelles je pouvais ressentir du désaccord, c’étaient les développeurs de mon camp. 😱Quand on partage une cause commune qu’on essaie de faire avancer, difficile de montrer trop ouvertement nos divergences de point de vue. En plus ça passe pour de la masturbation intellectuelle d’experts, ce qui est souvent vrai.
Quant aux autres développeurs, ils étaient juste dans un autre monde pour moi et l’échange restait à un niveau peu fertile.
Mais là, j’ai enfin un vrai ennemi : on défend des positions diamétralement opposées et assumées.
J’avais peur que sa réponse n’appelle pas vraiment à commentaire et continuer le drama sur du vide. Mais quelle joie d’écouter sa réponse !
Alors j’affûte mes arguments.
Je chauffe l’octogone.
Et je te donne rendez-vous bientôt sur la chaîne pour ma réponse. 😈
Gardez quand même en tête que Kevin ne sait pas de quoi il parle quand il parle de TDD.
Pour lui, on écrit un nouveau test à chaque nouvelle fonction. Pas étonnant qu’il croie que TDD ça ralentit!
J’ai pas vu le drama mais j’aime ton article.
J’ai commencé le TDD sur un SaaS que je développe et commercialise seul. Personne pour me dire que l’investissement n’était pas nécessaire, c’était une occasion parfaite.
Maintenant, il n’y aura plus de retour en arrière. Le TDD, c’est ce qui me permet de déployer de nouvelles fonctionnalités rapidement sans craindre de régression. C’est ce qui me permet d’affirmer que mes calculs sont exacts et que l’utilisateur a du entrer une mauvaise donnée, quand je reçois une demande de support. C’est ce qui me permet de mettre les libraires à jour régulièrement.
Bref, passé l’investissement initial principalement du à mon manque de connaissance du TDD et des libraires de testing, le TDD est un gain de temps énorme. Temps que je peux passer à vendre mon SaaS.
Merci pour ton retour.
C’est moi où il y a une tendance à l’extrémisme des deux côtés? Perso, je trouve que le TDD c’est overkill pour certaines choses et très bien pour d’autres. Il y a d’ailleurs des gens qui disent qu’il faut absolument utiliser le TDD car c’est comme un GPS, ça te guide, etc.
Oui c’est cool donc quand je connais pas du tout l’itinéraire. Est-ce que j’ai besoin du coup d’un GPS pour aller chercher du pain à 15 mètres de chez moi?
T’as certains tuto TDD, où les mecs prennent 1h juste pour faire des algo basics type moyenne pondérée en TDD alors que je trouve pas du tout adapté pour ce type de problèmes triviaux.
Bref, on s’en fout non si à la fin le dév délivre le code qui marche et les tests qui font avec? Si il a fait en TDD ou non, c’est vraiment important si son code est clean, élégant, testé, etc. ?
« Si il a fait en TDD ou non, c’est vraiment important si son code est clean, élégant, testé, etc. ? »
Si c’est plus efficace et plus rapide de le faire, je ne vois pas pourquoi s’en priver…
J’ai découvert ce drame entre toi et Kevin aujourd’hui autour d’un lunch avec un de tes prochains invité.
J’ai fais plus fort, sans connaitre votre drame de tous les deux, je l’ai invité à participer a l’un de nos prochains meetup de la communauté Crafts Romandie. Qu’il présente son point de vue à la communauté.
Comme le poste que j’ai fait aujourd’hui sur linkedin, la communauté crafts doit rester pragmatic et ne pas s’enfoncer dans le puriste. Si certain pensent aujourd’hui que le TDD, DDD et autre pratique n’avance rien dans le développement d’application. Alors a nous de comprendre pourquoi, peut-être qu’il y a une autre façon d’aborder le sujet. Mais je pense pas les drama en mode jardin d’enfant ne va rien régler.
A nous de montrer que nous sommes des adultes et comprenons qu’il y a des points de vue divergent qui vont nous amener d’autre challenge.
Cher Benoit, il me semble qu’il y un biais limitant dans le débat, qu’est ce que le métier de développeur ?
Si ton métier est de créer de la valeur pour un utilisateur en façonnant de l’immatériel, cette formulation me parait intéressante, « si le code n’a pas suffisamment de valeur pour le faire proprement » autant ne pas le faire.
Et si le développeur ne sais pas si son code va créer suffisamment de valeur pour l’utilisateur, il est probable que sa priorité ne devrais pas d’ouvrir son IDE.
Force est de constater que de nombreuses personnes qui exercent / pratique le métier de développeur n’ont pas une activité directement liée à la création de valeur pour les utilisateurs 🙂
Que ce soit difficile à mettre en place, à avoir le déclic, que ce soit naturel et fluide je peux comprendre. Qu’un développeur dise ça sert à rien je suis choqué comme dirait un grand philosophe.
Tout développeur avec un minima d’expérience et de recul/introspection sait que les tests c’est un sacré filet de protection avant livraison et encore plus dans le temps si ça marche et nécessite des évolutions (la mise en place à posteriori est une plaie et a un coût non négligeable). Ça sert à rien pour une MVP ? Ça évite 90% du temps à sortir la phrase : « c’est l’effet demo ».
Le TDD amène en plus à challenger sa conception/son archi de code (avec le nez dans le guidon c’est rarement facile, c’est un bon outil).
Pour le DDD, mais même pour une early startup, un bon event storming pour dégager les domaines, les interactions, etc. c’est le meilleure moyen d’éprouver notre solution et idées, de lotir, de définir le MVP, etc.
C’est vrai que je vois pas mal de ce genre de post sur LinkedIn (ou ailleurs).
Me concernant, j’essaye au maximum de pratiquer le TDD.
Des fois ce n’est pas possible, notamment quand tu débarques sur des projets déjà avancés.
Hehehe c’est marrant tout ça.
Ce que je trouve rigolo ce sont les expériences de Kévin, au mieux il a duré 2 ans sur une mission tout le reste était des missions courtes de moins d’un an.
Donc c’est facile de dire que la méthode de travail ne sert à rien quand on se barre avant de voir les problèmes que posent de faire du code de merde.
J’ai eu plusieurs missions de plus de 3 ans et c’est là que tu ressens tous les avantages de coder « proprement ».
Mais bon comme tu dis les chiffres sont du côté de Kévin simplement parce qu’il dit que les choses qui coûtent de l’argent ne servent finalement à rien.
Sur des missions de moins d’un an tu te fiches de faire de la rustine étant donné que tu seras parti et que ce n’est pas toi qui va gérer le problème.
Le craftmanship c’est syndical, c’est politique.
Les pratiques craft et TDD permettent la qualité des conditions de travail et assurent la qualité du livrable.
Ces pratiques ne font pas l’unanimité dans la culture IT pour de différentes raisons, notamment parcequ’elles ne permet tent pas, à la plus part des ESN ou autres intermédiaires , de vendre plus de prestation.
Par ailleurs, d’un certain point de vue « business » pour les intermédiaires, mieux vaut un système bancal ou poussif à maintenir avec une armée de gars ou un expert indélogeable et bien cher qu’un système bien conçu qui nécessite moins d’effort à maintenir et faire évoluer.
Comme dit mon fiscaliste : ce que vous ne payez pas à l’entrée, vous le payez à la sortie.