TDD / DDD / Clean Architecture : accélérateurs ou ralentisseurs ?

Eh bien les deux en fait !

Si tu suis sur LinkedIn / YouTube l’actualité craftsmanship francophone, tu n’as pas pu passer à côté du récent “drama” entre Kevin et Benoit.

Pour résumer rapidement, il s’agit d’un débat pour savoir si les pratiques crafts sont adaptées aux startups.

Benoit avance que oui, évidemment, puisque les pratiques crafts ont pour objectif de renforcer la qualité et la rapidité du feedback. Feedback qui est littéralement vital pour une startup !

Kevin de son côté explique que c’est une perte de temps, car les soi-disant avantages des pratiques crafts ne s’observent que dans un futur totalement hypothétique pour une startup.

Mon dieu… Que de quiproquos entre eux dans ces deux vidéos !

En fait, Kevin et Benoit ne parlent pas de la même chose.

Benoit se concentre sur le TDD dans le contexte d’une équipe qui le maitrise. Kevin parle lui plutôt de l’entrepreneur tech seul dans sa chambre, pas forcément expérimenté techniquement, qui fait tout pour sortir quelque chose le plus rapidement possible pour le confronter au marché.

Kevin parle des pratiques crafts en général : TDD, Clean Architecture, DDD. Pour le DDD, j’ai le sentiment qu’il parle principalement de technique, donc des patterns tactiques, puisqu’il parle “d’overkill”, ce que je traduis ici par “overengineering”, alors que Benoit parle plutôt des patterns stratégiques, ceux qui visent à mieux comprendre les besoins utilisateurs et les notions “métiers” du projet. Certes, une startup très early stage n’a pas de “métier” à proprement parler, comme le souligne Kevin. Mais elle gagne quand même à savoir de quoi elle parle quand elle mentionne tel ou tel terme, à partir du moment où plus d’une personne travaille sur le projet.

Eh bien les deux ont raison ! Et cela se résume à une notion bien connue depuis longtemps dans le monde logiciel : le coût du changement en fonction du temps passé.

Le coût du changement, c’est ce que coûte la réparation de bugs ou la modification d’un logiciel à mesure que des évolutions sont nécessaires suite aux feedbacks du marché. Pour n’importe quelle entreprise, mais SURTOUT pour une startup early stage pre product market fit, c’est extrêmement important de minimiser au maximum ce coût.

Les pratiques crafts sont là pour minimiser ce coût. Mais à la condition sine qua none de maîtriser ces pratiques !

Et contrairement à ce que dit Kevin, c’est bel et bien démontré ! Dans l’étude Accelerate, des milliers d’entreprises ont été sondées sur leurs pratiques. Et pour le dire vite, les toutes meilleures équipes en termes de stabilité et de fréquences de déploiement étaient celles pratiquant les pratiques crafts (dont le TDD). Mais encore une fois, si ces pratiques sont maîtrisées !

Dans la méta étude que cite Kevin, les résultats sont complètement faussés, car ils ont pris en compte des équipes ne pratiquant pas un TDD maitrisé ! On peut le voir dans les conclusions puisque les auteurs parlent de “tests écrits pour chaque méthode, dans chaque classe”, voire des équipes se revendiquant faire du TDD mais qui avouent avoir écrit les tests après…

Toujours cette confusion de ce qu’est vraiment le TDD…

Confusion qui revient souvent aussi, c’est que le TDD met plus de temps, car on écrit plus de code, et qu’on ne passe finalement pas son temps dans le debugger. Kevin en parle dans sa vidéo. Il avance notamment le fait qu’écrire du code en plus prendra nécessairement plus de temps qu’écrire juste du code, ce qui est vrai bien sûr ! Il dit aussi que finalement, le debugger on ne l’ouvre pas si souvent, et que l’argument de “le temps passé à écrire des tests est largement rattrapé par le temps non passé dans le debugger” est fallacieux, car en pratique personne ne passe vraiment beaucoup de temps à débugger grâce aux langages fortement typés qui permettent de trouver beaucoup d’erreur directement, et que la majeure partie des erreurs sont en fait des erreurs d’intégration avec des outils externes, là où le TDD n’est pas le plus efficace.

Eh bien, je suis d’accord avec lui sur le debugger ! Le temps économisé n’est pas tant dans le debugger, mais dans l’économie des tests manuels ! Tous les développeurs testent leur code, au moins manuellement, et quand on veut aller vite, rien de plus frustrant que perdre du temps à ouvrir l’application, parcourir 3 écrans, pour arriver enfin au formulaire qu’on veut tester, puis recommencer, etc. Heureusement, le hot reloading permet de pallier un peu ça, mais ça reste inefficace. Puis quand on ajoute des fonctionnalités, surtout en startup early stage, la dernière chose dont on a envie, c’est de devoir re-tester toute l’app avant chaque mise en production ! On veut le feedback des utilisateurs le plus rapidement possible !

Ce qui m’amène à te présenter un petit graphique totalement pas scientifique et complètement subjectif, mais qui est je pense très parlant :

Comme tu peux le voir sur ce schéma, la meilleure option pour minimiser le coût du changement, c’est si l’on maitrise le TDD, le DDD et la Clean Architecture. Dans ce contexte, et uniquement dans ce contexte, il est plus simple d’itérer, et ainsi de maximiser le feedback.

En revanche, tenter de “bien faire” en appliquant le TDD, le DDD et la Clean Architecture est la PIRE solution si ces pratiques ne sont pas maîtrisées ! C’est la catastrophe assurée pour n’importe quelle entreprise, et encore plus pour une startup early stage !

Pareillement, essayer d’apprendre ces pratiques pendant un projet est extrêmement coûteux durant une longue période du projet (qui dépend évidemment de la vitesse de compréhension et d’adaptation à ces pratiques de l’équipe). Le retour sur investissement se voit beaucoup trop tard pour un projet en startup, c’est aussi la mort assurée.

On fait quoi du coup ?

J’ai un biais évident ici, puisque je vends un service de coaching et de formation autour des pratiques crafts.

Pour autant, j’ai une approche pragmatique. JAMAIS je ne conseillerais à un pote qui démarre sa startup de se lancer dans le TDD, le DDD et la Clean Archi s’il ne maitrise pas ses concepts. Ce serait l’enterrer vivant.

Je suis même assez convaincu qu’il gagnerait plus à suivre le programme de Kevin The Arena Project pour apprendre à mettre les mains dans le cambouis et se démerder rapidement, concrètement.

Maintenant, pour un.e développeurs.se qui souhaite se professionnaliser dans sa pratique pour être capable de réduire le coût du changement au sein d’une équipe, je ne peux que leur conseiller de se former sur les pratiques craft, ce sera long, douloureux, mais le retour sur investissement sera énorme. Auquel cas, je lui conseillerais certainement de suivre le Cursus Artisan Développeur de Benoit.

C’est de la responsabilité de chaque développeur.se de continuer à se former toute sa vie, ça demande de la passion, de l’abnégation, mais c’est aussi ce qui rend notre métier si grisant.

Peut-on réussir sa startup sans ces pratiques ? Évidemment que oui ! La très grande majorité des startups qui ont levé des fonds n’ont pas ces pratiques, et les mettent en place après avoir levé des fonds et monté une équipe. Si ton objectif est juste de devenir riche, de faire un exit rapide pour aller monter une autre startup derrière, sans te soucier de l’évolution de ta startup, alors probablement que ces pratiques ne sont pas pour toi ! Les dizaines / centaines de millions d’euros levés serviront à réparer la dette technique créée, ils seront dépensés pour refaire l’application 1, 2, ou 3 fois (l’application Uber a par exemple été refaite 3 fois !), à la place de créer de nouvelles fonctionnalités qui pourraient être utiles aux utilisateurs. On pourrait littéralement empêcher des milliards d’euros / dollars d’être jetés par les fenêtres chaque année si les logiciels étaient mieux conçus pour minimiser ce coût du changement. Au final, ça se résume simplement à une responsabilité personnelle, la mienne, c’est celle prônée par le Software Craftsmanship : faire monter le niveau général de l’industrie, pour améliorer l’expérience de chaque développeur.se et rendre son travail plus gratifiant, et permettre probablement que ces milliards soient mieux investis ;)

Happy Coding :)

Pierre.