Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent
vivre une carrière épanouissante.
Prêt à passer au niveau supérieur ? C'est parti !
Bonjour !
Bonjour ! C'est pas la première fois que tu viens
sur le podcast et je suis ravi que tu sois encore là aujourd'hui.
Mais pour ceux qui ne te connaîtraient pas, est-ce que tu peux te présenter en quelques
mots ? Très bien, merci encore Benoît pour l'invitation.
Je suis Arthur Magne, City OECO fondateur d'une startup qui s'appelle ProMize.
C'est une startup qu'on a créée plus d'huit ans maintenant, c'est comment ça fait un
petit peu.
On est spécialisé dans la qualité officielle mais plutôt accès sur le partage d'expertise
dans les équipes de développement.
Et on essaye d'accompagner les équipes justement à se partager des skids, des expertises
sur l'écriture de tests, sur le code, sur l'architecture, etc.
Et ça tu le fais au travers d'un produit ? Je pense que c'est important de le préciser.
Tout à fait, on n'est pas une ESN, on n'a pas forcément d'expertise forte en interne
nous-mêmes sur ces sujets-là.
Donc on a juste développé des plugins pour les IDE et pour les outils de revue de code
comme GitHub ou GitHub qui vont permettre aux équipes de développement de remonter en
expertises directement pendant qu'ils sont en train de coder ou lorsqu'ils mettent
un commentaire dans une revue de code pour dire « tiens ce commentaire, il est intéressant
je vais pouvoir le partager avec toute mon équipe ou avec toute mon entreprise et je
vais enregistrer tout ce qui est dit là-dessus ». Il essaye de capitaliser vraiment pour
l'entreprise au maximum sur toutes les expertises de tout le monde et qu'on n'est pas de personnes
qui concentrent vraiment d'expertises comme ce qu'on connaît avec des faits de héros
un petit peu dans les entreprises sur un sujet précis.
Et justement, tous ces outils que vous avez créés, vous êtes passé progressivement
au TDD et au Kraft et l'objet de cet épisode c'était de faire un espèce de retour d'expérience
sur ça.
À l'heure où on enregistre cet épisode, je ne sais pas exactement quand il sera publié
mais il y a une semaine ou deux, il y a eu le premier YouTube drama sur le TDD en francophonie
et avec un gars qui s'appelle Kevin, qu'on s'allume au passage, salut Kevin si tu écoutes
cet épisode et qui avait une thèse contrariante pour moi qui était de dire que le TDD ça
ne servait vraiment rien en startup et toi, en tout cas dans les phases early stage, et
tu n'étais pas d'accord avec ça si j'ai bien compris.
Et du coup, je trouvais ça super intéressant qu'on repart de ton parcours, de comment
vous avez démarré, quelles sont les pièges dans lesquelles vous êtes tombés au début
et puis à un moment donné, qu'est-ce qui fait que vous êtes passé au Kraft ?
Oui effectivement, c'est vrai que j'ai suivi un petit peu ces échanges avec Kevin et
ça m'a fait penser à notre histoire parce qu'on a démarré vraiment la startup directement
quand je suis sorti d'école, donc je sortais juste de mon master à l'université, c'est
en 2014 et on a tout de suite écrit la startup.
Donc j'ai pas eu d'expérience avant en entreprise, je n'ai pas eu de mentor qui
m'ont accompagné sur les bonnes pratiques des choses à appliquer ou pas.
Donc on a un peu tout découvert sur le terrain et maintenant depuis plus de 8 ans, on a eu
une évolution dans nos manières de faire justement de produire du code qui a fortement évolué.
Et c'est vrai qu'on a en discuté ensemble.
Si c'était à refaire, je ne ferais pas du tout de la même manière ce qu'on a fait
et on est passé un peu par toutes les phases du code rapide, sans test, sans qualité,
du test after, du TDD, d'actin architecture, etc.
Effectivement, ça peut être intéressant que je donne mon retour d'expérience, donc
vraiment ce qui s'est passé chez nous autour de cette évolution.
Comment est-ce qu'à un moment donné, vous vous êtes dit « tiens, c'est intéressant,
qu'est-ce qui fait que vous êtes dit « on va s'intéresser au crave, tout ou on va
regarder de près le TDD ? » ?
En fait, si on repart du début, déclaration de la startup, qu'est-ce qui se passe ?
Et c'est à peu près pareil pour l'ensemble des startups, donc je vais peut-être généraliser
un petit peu.
Mais souvent, tu démarres, tu as un budget qui est limité, tu as un an par exemple pour
sortir un produit, sortir un MVP et essayer de trouver tes premiers clients.
Et à ce moment-là, tu dois sortir rapidement de la fonctionnalité, donc tu es tout de suite
sous pression.
Tu as une équipe qui est assez petite, mais on était trois développeurs.
Et notre objectif, c'était à partir d'une idée qui était justement cette idée de
permettre aux équipes de développement de se partager des skills et de l'expertise,
de pouvoir faciliter leur vie justement dans ces échanges.
Donc ça peut prendre plein de formes, une plateforme web, des plugins IDE, etc.
Mais au début, on n'a aucune idée de ce qui va apporter de la valeur aux équipes et aux
clients.
Donc il y a toujours ce truc qui revient en ce moment de se dire, est-ce que c'est plus
important de mettre l'accent sur l'outcome ou sur l'output ?
Donc l'output en gros, c'est le nombre de features que tu vas sortir, vraiment des
livrables précis.
Et l'outcome, c'est la valeur que tu vas tirer de part ces différents livrables.
Et les gens disent que ce qui est plus important, c'est la valeur.
Et c'est de se concentrer là-dessus, donc de faire moins de features et de sortir de
la valeur.
Alors c'est vrai, mais en fait, on n'est pas devin et cette valeur, on ne sait pas
où elle est.
Si les gens savaient où était la valeur.
Donc pour la chercher, il faut que tu fasses un peu de volume.
Exactement.
Tu as compris, en fait, on doit passer par cette phase de sortir un maximum d'output
pour découvrir en fait où est la valeur.
Qu'est-ce qu'il n'y a pas de valeur ?
Qu'est-ce qu'il y a beaucoup de valeur ?
Donc au début, en startup, tu te mets à sortir le plus vite possible de maximum de
fonctionnalité, donc d'output.
Et le problème de ça, ce qu'on a eu nous au début, c'est que tout de suite, on est
rentré dans cette phase de, on sort rapidement des fonctionnalités, on en sort le maximum
et on va les mettre un petit peu dans les mains des clients.
Et donc on a mis de côté vraiment tout cet aspect de qualité.
Pourquoi ?
Parce qu'on avait vu aussi ces conférences qui datent maintenant un petit peu, qui sont
plus du toit à jour, qui disaient qu'on va avoir la qualité, le délai et le scope
qui sont trois composantes d'un logiciel.
Et en fait, tu ne peux pas avoir les trois en même temps, d'après ce qu'on pouvait
entendre un petit peu à l'époque déjà.
Et donc tout de suite, on s'est dit, bon, du coup, nous, on a des délais qui sont carrés,
on doit sortir plein de fonctionnalités.
Donc vu qu'on ne peut pas tout avoir, on va mettre la qualité de côté.
Donc on ne va pas vraiment faire attention à tout ce qu'il y a avec une code, architecture,
et on ne va pas tester non plus parce que des tests, bon, peut-être que pour une
start-up, ce n'est pas adapté.
Donc là, on revient un petit peu à ce que disait Kevin.
Voilà, est-ce que c'est adapté ou pas de faire ça ?
Donc on s'est dit, on ne va pas faire de test et on va peut-être aller plus vite.
En fait, ce qui s'est passé, c'est qu'on a sorti des fonctionnalités très rapidement,
des fonctionnalités, bon, il y a eu d'autres problèmes.
On les faisait un peu trop génériques, on rajoutait de la complexité là où il n'en
fallait pas, on rajoutait des niveaux, par exemple, de gestion de permission, de gestion
de notification, des choses comme ça, alors que ce n'était pas vraiment essentiel pour
une start-up, en fait, il vaut mieux se concentrer pour sortir de le moins de fonctionnalités
possibles mais des fonctionnalités qui fonctionnent très bien et qui vont vraiment apporter
de la valeur au client tout de suite.
Et donc on a fait beaucoup de choses, on a rajouté beaucoup de contexte.
Donc au début, ça allait bien, mais quand je dis au début, c'était vraiment les
tout premiers mois et très rapidement, on s'est rendu compte qu'on est tombé un peu
dans la problématique de l'anthropie logicielle.
Arnaud Lemer, on parle beaucoup dans ses conférences.
L'idée, c'est de se dire que le logiciel a une tendance naturelle à se désordonner
et lorsqu'on rajoute de la complexité dans le code et dans les fonctionnalités, on va
désordonner plus vite.
Et tant qu'on ne fait pas de refactoring ou qu'on ne retravaille pas justement ce code,
cette anthropie va faire qu'augmenter et donc la complexité va un petit peu rendre
trop complexe notre logiciel.
Et c'est exactement ce qui s'est passé chez nous.
En quelques mois, on s'est rendu compte qu'on avait beaucoup de fonctionnalités qui fonctionnaient
plus très bien.
Dès qu'on rajoutait des choses, il y avait des choses qui cassaient un petit peu à droite
à gauche.
Alors le point de vue de Kevin, c'est de dire justement comment on ne sait pas où on va,
comment on ne sait pas où est la valeur, allons plus vite.
De toute façon, on n'est pas sûr de dépasser ces quelques mois que tu viens d'évoquer.
En fait, lui, ce qu'il dit, c'est qu'on va...
Alors après quelques mois, je pense que le phonique il doit y être, mais pas forcément.
Donc lui, son point de vue, c'est de dire que ça ne sert à rien de se prendre la tête
parce que plein de boîtes n'atteindront même pas le stade de ces quelques mois.
Effectivement, nous, c'était un petit peu notre idée aussi au début et donc on a
testé comme ça.
Et on s'est rendu compte qu'en réalité, assez rapidement, on a sorti beaucoup de fonctionnalités,
beaucoup de choses, mais on aurait pu limiter beaucoup plus ce scope en fait.
On aurait pu sortir quelques fonctionnalités principales juste pour valider vraiment l'intérêt
et sortir ces fonctionnalités de la bonne manière.
En fait, on a sorti beaucoup de choses de mauvaise manière et là, on a perdu beaucoup
de temps par la suite parce qu'à ce moment-là, on a eu beaucoup de bêtes qui sont arrivées,
on s'est mis à faire des heures supplémentaires, à travailler de week-end.
Oui, ça commence à ressembler à un sac le vision.
En fait, tu as beaucoup de problèmes, tu as beaucoup de complexité, du coup, tu tires
sur les équipes, ça fatigue, du coup, plus tu fais encore des choses qui se dégradent
et qui empirent.
C'est ça, tu veux aller encore plus vite.
Donc du coup, à ce moment-là, tu te dis les tests, c'est même pas une question à se poser,
on n'a pas de temps, on ne peut pas les faire, etc.
Donc ça a été vraiment très compliqué.
Ça a duré un an, deux ans, donc on a réussi quand même à avancer.
Mais le produit en lui-même, en fait, c'était vraiment dégradé en termes de qualité.
Et c'est plus tard qu'on a compris qu'on faisait « false-truth ».
En réalité, c'est possible d'avoir la qualité, le délai et le scope ensemble.
Et il y a beaucoup de conférences en ce moment qui poussent dans cette direction.
Et elles expliquent que la valeur en réalité, la valeur que tu produis, c'est la qualité
divisée par le coût global.
Quand on parle de qualité, on parle à quel point je rentre service aux clients,
à quel point ma fonctionnalité a dû y rendre service,
elle n'est pas buguée, elle est facile à comprendre, etc.
Et le coût global, ce n'est pas le coût de développement.
Donc le temps que tu as mis avec ton équipe à développer la fonctionnalité,
c'est le coût de création plus les coûts de maintenance que tu veux avoir derrière.
Donc la facilité à maintenir cette fonctionnalité,
l'appris en main de support.
C'est-à-dire, si je fais une fonctionnalité qui est très complexe,
est-ce que je vais avoir à recruter une personne qui va faire du support
toute la journée avec les clients parce que la fonctionnalité est vraiment trop complexe ?
En fait, il faut vraiment réfléchir un petit peu à tout ça.
Et quand on prend en compte ce coût global,
on se rend compte que ça ne sert à rien justement de faire des fonctionnalités
rapidement qui ne seraient pas faciles à maintenir,
parce que ça va avoir un coût qui est énorme.
Et même pour une start-up, quelques semaines et quelques mois,
on sent quand même vraiment quand il y a des fonctionnalités complexes
à maintenir que c'est un impact super fort.
Qu'est-ce qui fait qu'à un moment donné,
vous êtes dit là maintenant, il faut vraiment qu'on change.
Et cette fois, on va y aller dans le craft, ça nous plaît.
On a vraiment envie d'aller apprendre à faire du TDD.
Alors ce qui s'est passé, c'est que le problème qu'on avait,
nous on s'est rendu compte qu'il y a beaucoup d'entreprises dans l'IT
qui l'avaient, tous ces problèmes de dette technique,
on va dire de retravailler du code, etc.
Et on s'est rendu compte qu'on avait de plus en plus de bugs,
on n'arrivait pas à sortir des nouvelles fonctionnalités.
Et en réalité, justement en start-up,
on doit sortir quelques fonctionnalités de base,
vérifier si ça marche ou pas avec les clients, si ça porte la valeur.
Et en fait, ces fonctionnalités vont évoluer.
Mais on ne va pas tout jeter et tout réécrire constamment.
On pourra avoir une approche comme ça de se dire,
on ne fait que des prototypes, on teste, on jette, on teste, on jette.
Ah oui, ça c'est vraiment, en plus, c'est un argument clé de Kevin,
c'est-à-dire, on peut faire de la merde, c'est pas très grave.
De toute façon, si ça marche, on refra.
Alors effectivement, dans la vraie vie, c'est pas vrai,
c'est pas vrai, c'est pas aussi simple, c'est pas vrai.
Oui, tu peux refaire, mais en général, quand tu refais,
c'est que y a tellement souffert, comme on le dit,
c'est plus possible, on fait.
Mais sinon, dans la vraie vie,
en fait, bien souvent, tu fais ce que tu peux avec le podcode,
pas terrible que tu récupères.
C'est ça, en fait, on s'est rendu compte,
et vraiment, notre point de vue là-dessus,
c'est qu'il faut faire le minimum,
mais il faut faire des choses super évolutives,
pour que justement, en fonction des retours clients,
qu'on va avoir très vite, qu'on puisse modifier ce qu'on a fait,
et on va passer notre temps, en fait, à modifier tout ce qu'on a fait,
et pas à jeter et refaire.
Et on connaît des startups, d'ailleurs, sur Bordeaux et ailleurs en France,
qui ont coulé à cause de ça,
parce qu'ils ont fait une nouvelle fonte au bout d'un an,
mais il a fallu tout réécrire tellement, c'était en été,
et en fait, le temps de tout réécrire, rien n'est sorti,
il y a d'autres concurrents qui leur sont passés devant,
et les startups ont coulé.
Tu veux dire que c'est hyper intéressant,
c'est plutôt un contraint exemple direct,
qui est de dire que la boîte avait bien trouvé
son début de business, avait su créer de la valeur,
mais au moment où il a fallu industrialiser,
il n'y avait plus forcément l'énergie disponible pour le faire,
et en tout cas, ils se sont fait doubler ou coiffer au poteau.
C'est ça, cette même dette technique,
c'est que, évidemment, si tu veux rembourser ta dette
en réécrivant tout le logiciel,
pendant six mois, un an, tu ne vas rien sortir de nouveau,
et des clients qui attendent justement des nouveautés,
ils vont aller voir ailleurs.
Et effectivement, c'est pour ça que c'est intéressant de,
même si on a une base qui est un petit peu ancienne,
et nous, c'était notre cas, notre base était sur du AngularJS,
et la réalité, c'est qu'aujourd'hui,
on a toujours beaucoup d'angulards.js dans notre code,
qu'on n'a jamais réécrit,
par contre, on a tout le nouveau code qu'on produit qui en réacte,
qui est fait en client architecture, etc.
Donc dans notre code, on retrouve des strats, en fait,
un petit peu comme en archéologie,
où si tu creuses et tu tombes sur des fichiers assez anciens,
tu vas voir vraiment une très ancienne manière de faire.
Par contre, toute ta base de code qui est évolue aujourd'hui,
elle est super clean, c'est de l'architecture hexagonale,
non-back, c'est d'une architecture dans le front, etc.
Et c'est ça qui est important, c'est qu'aujourd'hui,
en fait, tu ne touches pas tout le temps toute ta base de code,
tu touches vraiment que le haut de l'iceberg.
Que ce qui est nécessaire, en fait.
C'est ça, que ce qui est nécessaire.
Et en fait, si tous les jours,
tout le nouveau code qui est produit,
il est produit d'une meilleure manière aujourd'hui à l'instant T,
tu ne vas pas te retrouver avec des problèmes de,
ah, on aurait dû tout réécrire.
Heureusement qu'on n'a pas tout réécrit,
sinon je pense qu'on n'aurait pu couler.
Parce qu'à ce moment-là, on aurait perdu énormément de temps,
et puis tu réécris tout en réacte,
et aujourd'hui, on va te dire,
bah non, en fait, ce n'est pas réacte, c'est Sved,
par exemple, ou c'est un autre framework,
tu ne vas pas constamment te mettre à réécrire toute ta base de code.
Donc ce qui s'est passé, c'est vraiment qu'à ce moment-là,
on s'est rendu compte qu'on pouvait produire quelque chose
qui ptait, qui marche,
et qui évolue facilement pour pas cher.
Et c'est en découvrant tout ce qui était
autour du mouvement Software Craftmanship.
Donc ce modèle du craft, c'était vraiment de transmettre un geste expert,
et d'essayer d'entrer dans un état d'esprit
et dans une culture de l'apprentissage pour faire des choses bien.
C'est à ce moment-là, c'était vers 2020,
où on a suivi la formation que tu donnais à Artisan Developers,
qui aidait justement à prendre un petit peu en connaissance,
un petit peu tous les concepts qu'il y avait derrière,
toute cette culture qu'il fallait mettre en avant,
et notamment le TDD.
Donc là, comme ça, on peut en parler un petit peu.
À ce moment-là, on s'est rendu compte
qu'on avait essayé d'écrire des tests,
mais on écrivait des tests après le code.
Du coup, ces tests, ils avaient une très faible valeur,
ils trouvaient très peu de bugs,
et ils étaient durs à maintenir, durs à écrire,
ils nous prenaient du temps.
Donc clairement, en fait, on a eu une très molle expérience sur des tests
en les écrivant après.
Par contre, quand on s'est mis à passer sur du TDD,
donc vraiment à écrire des tests avant,
ça nous a vraiment changé la vie,
dans le sens où on n'a pas eu trop de difficultés
à prendre vraiment ce geste d'écrire de tests,
puis ensuite d'écrire de code qui échoue,
et ensuite d'écrire de code qui fait passer le test,
et de refactorer.
Ça a été un changement dans l'équipe assez rapide.
Et d'un seul coup, on n'avait plus de problèmes sur les fonctionnalités,
donc on n'avait presque plus aucun bug
qui était lié justement à des erreurs de code.
Donc on avait une bien meilleure confiance
en fait dans le code qu'on produisait.
Les revues de code étaient plus rapides
parce qu'on se concentrait essentiellement sur les tests.
Donc en fait, on n'avait plus regardé dans le code,
est-ce que vraiment ça marchait ou pas ?
On regardait juste les tests qui avaient été rédigés
pour vérifier si tous les cas ont été pris en compte.
Et si c'est quand même été pris en compte,
on faisait une petite passe très rapide sur le code,
mais en général, on n'avait pratiquement rien à dire.
Donc vraiment, ça nous a augmenté la confiance qu'on avait dans notre code.
Donc un lit de time qui était beaucoup plus rapide,
c'est-à-dire qu'on pouvait mettre en production plus rapidement
sans avoir une phase de QA un petit peu à l'ancienne
où tu fais la fonctionnalité
et puis ensuite tu dois tester pour vérifier que ça n'a rien cassé
et puis tout tester un petit peu manuellement.
Ça, vraiment, on ne le faisait plus tout.
Et derrière, on allait beaucoup plus vite, justement,
pour tout ce développement.
Et petit à petit, on a mis en place derrière
les principes de clean architecture dans le front
pour découper justement le framework
que ce soit en Godard.js ou React, de la logique métier.
On s'est mis à rajouter des tests un petit peu dans la partie front-end.
On a mis en place de l'architecture exacte qu'on a dans le back, etc.
Et c'est vraiment le TDD qui nous a tout lancé,
qui a vraiment lancé cette démarche
de changer notre paradigme, notre manière de faire
pour être capable d'avoir confiance en ce qu'on faisait.
Et c'est à ce moment-là, d'ailleurs, quand on a démarré le TDD,
qu'on a arrêté les heures supplémentaires,
qu'on a arrêté vraiment de travailler le week-end ou quoi que ce soit
pour essayer de terminer le temps.
Et on s'est dit, au final, on a un temps qui est borné.
C'est les heures de travail qu'on a dans la semaine.
On n'a pas le droit de dépasser ce temps-là.
Donc, c'est à nous de produire le maximum de valeur en un minimum de temps.
Et c'est un petit peu la discipline d'ingénierie
qu'on retrouve aujourd'hui.
Il y a plein de personnes qui poussent ça, qui disent que les ingénieurs
ils ont pour objectif de produire le maximum de valeur en un minimum de temps.
En gros, tu dois gagner du temps.
Tu dois essayer de trouver des astuces pour gagner du temps.
Et de TDD, pour nous, ça a été vraiment une astuce
pour gagner beaucoup de temps, justement,
sur tout développement et sur tout astuces.
Dans cette question sur le...
Si tu as eu cette question de, est-ce qu'on gagne du temps tout de suite ?
Est-ce qu'on perd un peu de temps d'abord pour le récupérer après ?
C'est quoi ton point de vue sur ça si tu bosse en TDD,
maintenant que tu sais le faire ?
On passe la phase où, effectivement, il a fallu que tu apprennes à le faire.
Je ne dis pas que c'est mineur, d'accord ?
Mais apparturement, tu sais le faire ?
Quel est ton sentiment par rapport à ça ?
À partir de quand, tu as l'impression d'amortir, entre guillemets,
le fait de travailler en TDD.
Pour nous, ce qui a été marrant,
c'est que dès le début, quand on s'est mis à faire du TDD,
on y allait par étape,
mais dès le début, on ne faisait pas du TDD comme on fait aujourd'hui.
On n'écrivait pas les tests de la même manière,
les moques, des choses comme ça.
Mais dès le début, ça a été rentable,
dans le sens où on passait un peu plus de temps à écrire la fonctionnalité en elle-même,
mais c'était déjà assez mineur.
On faisait peut-être x1,5 ou x2 sur une fonctionnalité.
Mais en réalité, écrire la fonctionnalité, ce n'est pas le bottleneck.
Écrire du code, ce n'est jamais le bottleneck.
Ce qui prend du temps, c'est tout ce qu'il y a autour de ça.
C'est la création de la feature, la compréhension.
Donc en fait, de faire décrire un peu plus de code et décrire des tests avant,
ça n'a jamais eu un impact très fort sur la productivité.
Par contre, ça a eu un impact très fort sur le nombre de retours qu'on avait,
sur la facilité à modifier ce qu'on avait déjà créé.
C'est vraiment ça le plus gros impact pour nous.
C'est très rapidement, en fait,
on s'est mis à pouvoir modifier tout ce qu'on écrivait beaucoup plus facilement,
en commençant par modifier des tests.
Et ça, ça nous a vraiment bien aidé.
Et maintenant qu'on est tous au point dans l'équipe pour justement faire du TDD
de manière beaucoup plus fluide,
effectivement, c'est quelque chose qu'on,
si c'était à refaire, qu'on ferait dès le début,
dès le démarrage de la startup, quitte à prendre un peu plus de temps au démarrage.
Parce qu'effectivement, on peut se dire, on est en startup,
on n'a pas un budget limité, donc il faut aller vite.
Mais il ne faut pas abuser non plus, entre guillemets.
Ça ne se joue pas au jour près ou à la semaine près.
Cette espèce de pression qu'on peut avoir
de vraiment aller très vite sortir des choses.
Aujourd'hui, j'accompagne d'autres startups en tant que mentor entre guillemets.
Et ça, dès début, je leur dis,
mais là, si vous avez un mois passé à réfléchir à quelque chose,
commencez pas à coder maintenant.
Attendez, attendez, attendez.
Vous inquiétez pas, le temps de développement que vous allez avoir derrière,
c'est vraiment pas ça qui est le plus important.
Il ne faut pas juste sortir plein de trucs au hasard.
Il faut vraiment réfléchir à tout ça.
Sortir quelques fonctionnalités principales qui sont vraiment le coeur de la valeur qu'on va livrer.
Et à partir de ce tronc qu'on va avoir, là, on pourra avoir plein de branches qui seront des dérivés de fonctionnalités
ou d'autres choses, etc.
Mais clairement, pour nous, du moins dans notre contexte,
ça n'a jamais, enfin, si c'était à refaire depuis le début,
je ne pense pas que démarrer en TDD,
ça nous aurait impacté la livraison justement des fonctionnalités.
Pas plutôt positivement, à l'arrière.
Si ça doit impacter, c'est tout ce que tu as dit.
C'était plutôt dans le sens de l'accélérer.
En fait, ce que je trouve intéressant dans ce que tu aimes,
c'est que dans ce temps en retour d'expérience,
c'est que tu as fait vraiment une corrélation, en tout cas, là, dans l'échange qu'on a eu,
entre le passage au TDD et l'arrêt des heures sup,
et je trouve ça assez fort quand même.
Donc, pour moi, ce que je comprends, c'est que l'augmentation de la qualité de code qui a été produit fait que
il y a eu plus de sérénité, la pression à baisser au sein de l'équipe.
Et ensuite, tu dis, ça nous a amené de la vélocité dans la capacité à modifier du code.
Et ça, je crois que c'est hyper riche.
Et notamment en startup, c'est essentiel d'être capable de réagir vite.
Tout à fait.
Et ça aussi, je trouve ça extrêmement fort.
On n'est même plus sur une question de Héroï,
on est sur une question de, je suis capable d'accélérer la machine.
Donc, tu vois, avec un retour d'expérience comme le tiens,
qui va plutôt dans mon sens,
dans mon sens au sens de mon retour d'expérience,
et aussi du coup de ce que je prends.
Je me dis, mais pourquoi ?
Pourquoi, pourquoi pas ?
Enfin, pourquoi non ?
Enfin, je veux dire, pourquoi ne pas le faire ?
En fait, on voit que tu vas plus vite,
tu es plus véloce.
Parfois, ça te ralentit un peu,
mais comme tu l'as dit, peut-être à la marge,
moi, je n'ai même pas de sentiment,
mais je veux bien croire que pour certains, ce soit le cas.
On évolue plus vite,
c'est exactement ce que tu veux en startup.
Pourquoi on ne fait pas plus ?
En fait, tu vois, ça, ça, et mais on avec le,
l'échange qu'on a avec Kevin, on a un début de réponse.
C'est que les gens sont encore persuadés
qu'il y a ce dilemme entre qualité et vitesse d'exécution.
Et tu as raison de le rappeler, il y a 20 ans de ça,
c'était le socle, c'était même le socle de,
de pourquoi on allait vers l'agilité,
tu vois, c'était de dire on ne veut plus miser sur la qualité tout ça.
Mais c'était encore une variable d'ajustement,
et ça, et dans la vraie vie, ça l'a, ça l'a toujours été.
Si tu penses que les trois qualités d'hélescopes sont opposables,
tout de suite, en fait, tu, tu vas avoir l'impression que c'est en opposition,
pour aller vite, tu es obligé de taper sur la qualité.
Et effectivement, c'est aujourd'hui,
c'est tout l'inverse, c'est ça, aujourd'hui, c'est vraiment dans notre métier,
on voit, on voit que dans notre métier,
mais ce n'est pas le cas partout,
et je pense que le, le problème bien de ce que,
ce, cette action est réelle dans la vie physique,
dans la vie physique, tu vas nasser de meilleures qualités,
ils coûtent plus cher, ils coûtent plus d'énergie,
plus de meilleurs matériaux, tu veux une meilleure voiture, elle est plus chère.
Parce qu'elle a une corrélation entre le coût de production et la qualité,
et encore certains ont montré qu'ils étaient capables de faire mieux,
machin tout ça, notamment Toyota,
avec des approches managerales différentes,
mais pour la faire courte, il y a une corrélation entre les deux.
Mais dans le monde virtuel, c'est tout l'inverse.
Et ça, c'est tellement contre-intuitif pour beaucoup de monde,
c'est qu'en améliorant la qualité, on va plus vite.
C'est ça, c'est vraiment le, ce qu'on retient à nous de notre expérience,
c'est ça, c'est de se dire,
si dès le début, on avait mis en place cette,
cette gestion vraiment de la qualité plus forte,
en fait, c'est vraiment quelque chose qui, maintenant,
par la suite, nous a permis d'aller beaucoup plus vite.
Et pour moi, ce côté, faire et défaire un petit peu de la start-up,
où on sait pas où il faut aller, etc.
C'est vraiment, je pense, personnellement,
une mauvaise idée de faire quelque chose,
de le détruire et de recommencer à zéro.
En fait, évidemment, on ne va pas complètement changer.
C'est-à-dire que nous, d'un seul coup, on ne va pas se dire,
en fait, on va partir sur, je ne sais pas,
la livraison de courses à domicile, par exemple.
Et là, évidemment, il faudrait tout réécrire.
Mais évidemment, tu as un cœur de métier qui ne bouge pas.
Et donc, tu dois construire vraiment le meilleur socle
avec les fonctionnalités principales qui aident
son fonctionnalité plus évidente.
Et ce socle va passer son temps à évoluer.
Et nous, je pense qu'il ne reste presque aucune ligne de code
qu'on avait écrit vraiment au tout début.
Tout a été modifié vraiment énormément.
On a eu des centaines et des centaines de milliers de dines de codes modifiés.
Pour autant, notre projet, en fait, il n'a pas vraiment changé en taille.
Il fait toujours peut-être 300 ou 400 millions de codes.
En fait, il passe son temps chaque année.
Il doit avoir 30% de la code base qui bouge, qui évolue.
Et si ce code était de mauvaise qualité, évidemment, on ne pourrait pas le faire.
C'est vrai qu'au début, avec cette notion de pression
et d'essayer de chercher des devets de fonds, etc.,
c'est encore pire parce que si jamais tu fais une devet de fonds,
mais que tu as quelque chose qui est de mauvaise qualité,
parce que tu t'es dit, je ne suis pas sûr que ça va rester dans le temps,
quand tu vas avoir ta devet de fonds et que tu vas devoir vraiment évoluer,
sortir des fonctionnalités, scaler,
avoir quelque chose qui passe vraiment à l'échelle,
qui est internationale, etc.
Si tu as une mauvaise base et que tu dois tout réécrire à ce moment-là,
c'est foutu. Surtout aujourd'hui, en plus avec la crise,
où justement les investisseurs aiment bien investir maintenant
sur des entreprises qui sont rentables, qui deviennent rentables très rapidement.
Pour ça, tu ne peux plus te permettre de faire une devet de fonds de plusieurs millions d'euros.
En te disant, mais pendant deux ans, il n'y a rien qui va sortir,
je vais juste réécrire tout ça.
Écoute Arthur, merci pour ce retour d'expérience.
C'était assez précieux si les auditeurs veulent te suivre, il peut venir où ?
Il peut me retrouver sur LinkedIn, en tapant Arthur Mann très facilement,
ou sur notre blog, sur le blog de Promise,
où justement on ne écrit pas mal d'articles autour de la gestion d'adeptes techniques,
je partage d'expertises, etc.
Merci Arthur.
Merci Benoît.
Quant à toi cher auditeur, la perche est tendue et trop belle pour que je ne l'apprenne pas.
Si toi aussi tu veux que j'accompagne ton équipe,
si tu fais partie d'une équipe et que comme Arthur,
tu souhaites bénéficier non seulement du cursus artisan développeur,
mais aussi d'un accompagnement et d'un coaching d'équipe,
ben tu connais mon adresse benoîtarobasartisandeveloppeur.fr
et on discute de ce projet.
Je te souhaite une bonne journée et je te dis à bientôt.