Retranscription : Radwane Hassen – Parcours 360 de Radwane, Architecte chez VP, Coach Technique et parti à NYC pendant 2 ans
Parcours en 360 de Radwane, Architecte chez Veepee, Coach Technique et parti à NYC pendant 2 ans
Retranscription du Podcast « Radwane Hassen – Code Insider »
César : Bonjour Radwane, merci d’avoir accepté de participer à ce podcast. Ravi de pouvoir échanger avec toi aujourd’hui. Tu es un des architectes de chez VP Tech et tu as aujourd’hui pas mal d’expériences dans l’IT et à l’étranger. Je suis curieux d’en savoir plus sur tes opinions concernant les bonnes pratiques, la tech et ce que tu as pu mettre en place dans des équipes. Le mieux serait que tu commences par te présenter.
Radwane : Bonjour César, merci à toi de m’avoir invité et avec plaisir. J’ai déjà de très bons copains qui sont passés, Rui et Thomas. Je suis architecte chez VP, et j’ai commencé à coder depuis 2008. Dans ce parcours technique, j’ai commencé avec de l’extreme programming, tout ce qui est agilité. C’était ma petite découverte et je trouve que depuis, c’est quelque chose qui m’est assez propre et cohérent avec mon parcours. J’ai fait pas mal de choses assez différentes, du coaching, du développement, du scrum développement, etc. Et aujourd’hui, je tente cette nouvelle casquette qui est architecte. Elle vient compléter un peu notre monde IT avec toutes les complexités qu’il y a dedans.
César : Génial, tu as déjà plein de choses intéressantes et un bon résumé. J’ai envie de te poser une première question. Puisque tu as parlé d’extreme programming, à quel moment est-ce que cela intervient ? Quand est-ce que tu entends parler des bonnes pratiques et que tu les mets en place ?
Radwane : Dès ma première expérience, je me suis retrouvé dans une boîte où il fallait que je m’organise par moi-même. Je n’ai pas eu de mentoring et j’ai dû me documenter. C’est une méthode itérative incrémentale qui pose les fondements de l’agilité. Donc j’ai essayé de faire des cycles d’itération court et je ne savais pas trop comment avancer dans ce projet.
César : Ça, c’est dès 2007 quand tu étais dans ta première boite de conseil ?
Radwane : Oui c’était mon premier travail. J’ai été un peu parachuté et il fallait faire un truc en 6 mois. J’ai fait quelques démos régulièrement et voir si ce que je proposais correspondait à ses attentes. Je vois que c’est assez familier dans le temps puisque généralement les clients ont un besoin bien défini mais ils ont du mal à l’exprimer. Et au fur et à mesure, je m’intéresse assez vite à ces méthodes agiles. C’est ce qui m’a amené à lire un livre assez important pour moi sur l’extreme programming : Livre Scrum et XP depuis les tranchées / Scrum and XP from Trench.
De base, je m’intéressais plus aux pratiques comme les tests, livrer et automatiser des étapes. Ce livre m’a fait m’intéresser à pas mal de méthodologies. Sur ma seconde mission chez PSA, j’ai eu la chance d’avoir un client qui m’a laissé des opportunités au bout de seulement 6 mois. On m’a demandé d’être le chef technique de l’équipe et je leur avais proposé de mettre en place de l’agilité.
César : D’accord, donc tu avais déjà pris le lead au travers de cette première mission et du livre qui te donnait envie d’implémenter des choses.
Radwane : Exactement. Et puis après, j’ai eu la chance de pouvoir faire le recrutement de mon équipe. Je suis tombée sur des personnes avec qui j’ai beaucoup appris. On a mis en place du TDD, du pair programming, un Kanban visuel dans notre open space. C’était quelque chose de très rare à l’époque et je me rappelle que certaines personnes venaient exprès par curiosité. A partir de là, je me suis de plus en plus intéressé à la communauté tech, et j’ai remarqué que plein de gens se posaient les mêmes questions que moi. J’y ai rencontré plusieurs amis avec qui on a voulu créer des conférences, dont Rui.
César : Alors avant de revenir sur cet aspect conférence, tu as dit un truc intéressant. « J’ai eu l’opportunité de m’occuper du recrutement de l’équipe », c’était une première pour toi ? Qu’est-ce que tu as appris ? Quels sont les éléments pour toi qui sont les plus importants lorsque tu recrutes ? Et ensuite, comment s’est fait ta montée en compétences sur tout ce qui est TDD, pair programming ?
Radwane : Assez vite, j’ai remarqué une préférence que j’ai pour certains développeurs avec qui j’aime travailler. Ce sont des développeurs qui sont très curieux, très ouverts à essayer des choses, à expérimenter. Et c’est la première chose que je cherchais à définir lors des entretiens, leur ouverture d’esprit et l’attrait pour la veille technique. Ce sont des questions que je pose encore aujourd’hui, comme « qu’est-ce que tu as appris récemment ? », « comment t’y es-tu pris ? ». Pour trouver les personnes plus curieuses que la moyenne et améliorer notre flow. On est dans un métier où l’un des fondements est l’amélioration continue et prendre le temps d’améliorer le tout est important.
César : Ça, ça permet d’avoir des équipes assez hétérogènes. Des personnes qui ont de nouvelles idées et qui vont monter le niveau de manière collective sur le plan technique. Comment est-ce que tu garantis le niveau technique ? En termes de tests techniques ou d’échanges, des questions sur de l’algo ou de l’archi. Ou c’est plutôt l’idée de pairer avec des personnes de l’équipe et d’essayer de voir si les pratiques sont similaires ?
Radwane : Alors je t’avoue que c’était un peu compliqué de mettre en place le pair programming. On avait beaucoup de stations fixes et les salles de meeting n’étaient pas forcément appropriées. Au départ, c’était plutôt des questions réponses, puis ça s’est transformé en véritable pair programming. Et même si ce n’était pas écrire du nouveau code, au moins on en regardait et on posait des questions dessus. Je trouve que c’est un peu plus précis comme discussions. Sur le pair programming, on a partagé de très bons moments à coder ensemble et à se poser des questions intéressantes. C’est assez difficile je trouve en une heure ou deux de voir les points forts et faibles d’une personne. Surtout quand on pose des questions d’algorithmie.
César : Oui donc ça te permet de voir la personne dans un contexte dans lequel elle est à l’aise et de pouvoir défendre ses positions.
Radwane : Exactement, on n’a pas toujours les mêmes intérêts et façons de faire. J’essaye de savoir où est-ce que cette personne se sent les mieux et où se situent ses forces. Ensuite, qu’elle me les démontre. Mais en général, quand on pose la question comme ça, les gens ont beaucoup de mal à répondre. Il faut s’acclimater en fonction des gens, tu auras des personnes qui seront hyper calées sur le hardware et tu peux voir leur méthodologie. On n’a pas besoin d’avoir l’exact même expérience pour être un bon développeur, capable de s’adapter. Quelles que soit la technologie, si la personne est ouverte d’esprit et a de bonnes bases, en trois – six mois, elle sera efficace. Je préfère ne pas fermer la porte à une expérience par rapport à une technique qu’il ne connaît pas.
César : Oui bien sûr. Avant de parler de ta première expérience, chez VP, anciennement vente privée, tu as parlé de TDD dans ton équipe. Comment se fait cette initiation ? Est-ce que c’était poussé par une autre personne ou alors ça s’est implémenté tout seul ?
Radwane : Ça s’est implémenté par étape. Au début, on essayait d’écrire des tests automatisés. Après, on a commencé à avoir une bulle d’automatisés, on a essayé de réduire la durée et d’augmenter leur performance. C’était principalement par du feedback que cela s’est fait, pour améliorer nos tests unitaires. On avait une base de code qui était du legacy, et il y avait des parties où c’était plus des harnais de sécurité que des vrais tests unitaires. Cela nous a amené à faire du refactoring par bout. Je me rappelle en 2010, j’étais allé à un user group autour du test. J’avais fait une première séance de pair programming avec quelqu’un qui était assez bon en DDD. Et ça a été assez révélateur pour moi.
César : Petite question, quand tu parles d’user group, cela fait référence à ce que l’on appelle aujourd’hui les meetups ? Ou c’était plutôt des choses en interne ?
Radwane : C’est exactement ça. C’était un meetup de ma boîte de consulting de l’époque, Valtec. On avait une communauté tech et parfois on faisait des cours du soir autour du TDD. J’ai pairé avec quelqu’un assez calé sur ce sujet, et qui m’a fait découvrir pas mal de chose. Il avait une approche plus orientée vers le design, mais pas forcément tournée vers les tests. Sauf que juste après, on jetait les tests, et ça, je ne l’avais jamais fait. En fait, tu ne gardes que les parties du code qui sont représentatives et tu peux limite les refactorer.
César : Ce que tu veux dire, c’est qu’au début, tu avais simplement la volonté de faire des choses plus qualitatives autour des tests. D’automatiser, de réduire la durée, de faire du refacto, etc. Et donc tu t’es forcé à faire un test qui le faisait d’une bonne façon et qui pourrait te guider autour de l’architecture. Et cela ressemble plus à du TDD que du Test First.
Radwane : Exactement. Finalement, on utilise les tests comme des outils de design, alors que mon objectif, c’est d’écrire des tests. Après, dans les deux cas tu vas avoir des tests à la fin, mais ce n’est pas la même approche.
César : Ok, et fort de cette expérience, c’est à ce moment-là que tu intègres Veepee, ou tu étais déjà là-bas quand tu implémentais ?
Radwane : Non non, j’étais encore chez PSA à l’époque. J’ai eu une autre expérience avant de rejoindre Veepee.
César : OK, et c’était dans la même continuité ? Ou il y avait de nouvelles pratiques, des choses nouvelles dans cette mise en place ?
Radwane : Non chez Veepee, il y avait plus de pratiques. On avait un développeur assez expérimenté, qui avait fait une mission originale juste avant. Où il était responsable de l’automatisation tests. Et donc il avait une très grande connaissance en BDD. Je connaissais un peu le BDD à l’époque, on avait essayé de faire du spec exécutable. On appelait ça du ATDD pour Acceptance Test Driven Developement. C’était à la base sur un wiki, contrairement à ce que l’on voit aujourd’hui avec Specflow. Donc avant, je n’avais pas une très grande connaissance, mais grâce à Veepee, j’ai beaucoup pratiqué. J’ai essayé d’écrire le scénario avec le product owner, Laurent, et il avait cette expérience sur le BDD. On l’avait implémenté avec pas mal de patterns.
César : Ça change quoi à l’époque, cette approche-là ? Il y a une notion de tester, de voir ce qui te guide dans l’architecture. Avec le BDD, tu viens tester le côté fonctionnel, alors comment est-ce que tu l’envisages ce contexte-là ?
Radwane : Au final, ce sont deux boucles de feedbacks. Une qui a une boucle plus importante autour du scénario fonctionnel, et l’autre c’est des plus petites boucles de tests unitaire autour du TDD. Cela structurait pas mal notre approche où à l’époque, on avait testé des parallèles. Ça n’a pas toujours été fructueux mais cela nous a aidés à nous retrouver, en combinant avec la méthode Pomodoro. On se disait que cela pouvait être un scénario Gherkin, puis que toutes les 15min on faisait un test unitaire. Cela nous aidait à faire un découpage, à voir comment on pouvait faire des parallèles, et découper des scénarios en plusieurs petites boucles de feedbacks. C’est vrai que cet aspect feedback, c’est ce que je tire le plus par rapport à l’approche TDD et BDD. C’est vraiment comment je valide une idée avec le cycle le plus court possible.
César : Oui c’est donc choisir la meilleure méthode agile d’un point de vue technique pour éviter le plus d’erreur possible sur le long terme. Et donc c’est à ce moment-là que, tu as deux expériences à la suite où tu pars plutôt sur du coaching technique. Comment se fait cette transition-là ? Tu avais déjà fait du pair programming et des tests un peu plus poussés, donc tu commençais à emmagasiner des bonnes pratiques de développement. Comment est-ce que tu as implémenté ça dans les équipes ? Et comment, dans des cadres comme la SG CIB, tu as pu faire monter en compétences des équipes techniques ? Et si tu as eu des développeurs qui n’était pas du tout familiarisés avec ces pratiques ? Tu nous parlais de pas mal de moyens, notamment avec le pair programming, mais est-ce que tu as utilisé d’autres choses ? Raconte-nous un peu le procédé.
Radwane : Alors, c’est vrai que j’ai toujours aimé animer des communautés ou des workshops. On parlait forcément des pratiques de Kata, de Coding Dojo. J’avais aussi animé quelques formations, donc j’avais déjà cette envie de transmettre, parce que j’apprenais en transmettant. Et c’est ça que j’avais essayé de mettre en place dans le coaching. Il est vrai qu’il y avait une partie de présentation du training aux équipes de développement pour montrer les pratiques, puis faire des Kata pour montrer les pratiques de tests.Après, on avait essayé de mettre des outils en place, qui nous donnent des indications sur la qualité du code. Ils étaient différents.
Certains étaient faits pour montrer la dépendance du code, un autre qui était dans le .NET et qui j’espère, existe encore, c’est le NDepend. Il montrait la dépendance entre les différents packages et projets. Finalement, le design pour faire court, il y a pas mal de choses que l’on peut expliquer avec le coupling et la cohésion du code. D’un côté, on va avoir le code le plus cohésif possible, et de l’autre, avoir un couplage qui soit faible, pour que les modules évoluent de la manière la plus indépendante impossible. Donc essayer de mettre en avant ces pratiques-là pour mettre en place un questionnement, de pourquoi ce code est problématique. Et pourquoi le test est intéressant ? Parce qu’un code qui est difficile à tester, c’est soit qu’il fait trop de chose, soit qu’il a beaucoup trop de dépendance.
Donc l’idée était de développer ce côté-là avec des discussions, du partage. J’avoue que c’est une approche un peu expérimentale, mais je n’ai pas envie d’imposer des techniques aux gens avec qui je fais du coaching. Je veux leur donner de l’intuition pour qu’ils les adaptent eux-mêmes à leur manière de faire. Je me rappelle d’une développeuse qui était excellente et avec qui j’ai fait du pair et du refacto, mais on avait un petit peu galéré. C’est normal, ce n’est pas évident d’arriver dans une base de code qui est un peu complexe et difficile à tester. Mais quand on y passe du temps et que l’on voit comment on peut le transformer, cela peut être une expérience qui change une vision. Le refactoring, ce n’est pas l’activité la plus simple, mais ça permet de trouver les endroits où il y a des opportunités.
César : D’accord, c’est vraiment mettre les mains dans le cambouis, voir au fur et à mesure comment cela fonctionne et trouver ses propres solutions en les expérimentant. Ce que tu me disais tout à l’heure me faisait penser à ce que me disait Thomas. Sur la notion de Cargo Cult, on en a aussi reparlé avec Guillaume Téchené. C’est intéressant parce que tu dis que tu as une approche très exploratoire, mais est-ce que ce ne serait pas ça, l’essence de l’agilité ? Aujourd’hui, des grands noms comme Rui Carvalho parlent de Scrum comme étant mort.
Est-ce que tu n’as pas ce constat là aussi, de te dire que l’approche exploratoire n’est pas forcément théorique, et qu’au contraire, chaque équipe et chaque développeur peut avoir des sensibilités différentes. Est-ce que cela t’a amené vers une méthodologie particulière ? On parle beaucoup d’expérimentation par le terrain, mais comment est-ce que tu vois cette dynamique organisationnelle ?
Radwane : Dès le départ j’ai eu un bon intérêt pour Scrum. C’est une des premières méthodes d’équipe que j’ai voulu mettre en place. Après, je ne sais pas si c’est une incompréhension ou quelque chose que l’on a perdu en cours de route, mais il y a une grande partie de l’amélioration continue qui est mise dans Scrum. Je trouve que ça apportait pas mal de chose et qu’il y avait des outils d’amélioration continue dedans. Aujourd’hui, si on l’applique de manière fixe sans le faire évoluer, effectivement c’est un entre deux.
Pour moi, le meilleur feedback loop que l’on peut avoir en termes de rapidité, c’est celui où l’on met en prod directement après avoir fini le développement. Et donc, on n’aurait pas à attendre une cadence et à subir des sprints. Donc oui, je trouve que c’est une bonne chose, la manière dont ça s’est implanté dans l’agilité, mais au final qui m’a plus servi en tant que transition. Une méthode que j’ai plus utilisée c’est le Scranban, un mélange entre Scrum et Kanban, avec moins de rituels. Et puis, on applique la méthode de Scrum de faire des rétrospectives, et de s’adapter aux besoins de l’équipe.
César : Oui, tu as un peu pris le meilleur des deux mondes, en te disant : « ok, je ritualise pas mal de bonnes pratiques. Si maintenant j’ai envie de faire avancer l’équipe et d’être sur une amélioration continue, je dois passer sur d’autres notions qui vont tout remettre en question. » Et donc le Scrumban était une manière de prendre ce qui t’intéressait le plus dans ces deux méthodes pour l’équipe.
Radwane : J’avoue que je me rappelle de moi au tout début, essayant de mettre en place cette méthodo dans toute l’équipe. Et cela m’avait bien plu, le fait d’avoir des marqueurs aussi clairs que ceux donnés par Scrum. C’était assez facile et il y avait très peu de pratique à mettre en place. Les entreprises le comprenaient bien donc c’était assez clair et cela remplissait un besoin à un instant t. Quand on dit que l’agilité, c’est Scrum, c’est un peu triste, même si je comprends leur constat.
Si je dois retenir deux choses de l’agilité et qui m’ont toujours touchées au plus profonds de moi, c’est le côté itératif et l’incrémental. On peut parler de ce qu’on veut, tout ce qui m’importe, c’est que l’on définisse un incrémental qui apporte de la valeur, et comment le faire de la manière qui m’apporte le feedback le plus rapidement possible. Il faut avoir une culture de l’excellence technique qui va apporter une sérénité à l’équipe et à livrer de la qualité régulièrement.
César : Hyper intéressant. Et donc, c’est à ce moment-là que tu as co-créé les Ncrafts, aujourd’hui les Newcrafts. Toujours dans cette dynamique de partage, que je pense tous les gens autour du coaching et de la formation partagent. Est-ce que ce ne serait pas aussi ça, la logique des Ncfrats, apprendre en transmettant tout en sortant du cocon des meetups ?
Radwane : C’est exactement ça. C’est d’une discussion que l’on a eu avec Rui et les autres. Ce sont des pratiques qui vont au-delà des technologies. On n’a pas besoin de parler de certains framework pour parler de certaines pratiques. Et l’on avait cette frustration qu’il n’existe pas de conférence agnostique, qui parle de pratique un peu plus réutilisable qu’importe l’approche ou la techno. On a parfois donné des noms d’outils, mais nous n’avons pas parlé de technologies précises. C’est ça qui est un peu moteur.
Et donc il nous manquait cette conférence, qui soit internationale, qui partage des pratiques, qui fédèrent les gens cherchant une certaine excellence, comme le Crafts ou autre.
César : Et justement Radwane, si tu devais m’évoquer deux trois talk qui t’ont particulièrement marqué, parmi toutes les sessions, lesquels serait-ce ?
Radwane : Oh bah, il y en a beaucoup. Je peux penser à Mathias, qui avait parlé du TDD, du Test Driven Development, et qui pour l’époque, n’était pas si connu. C’est un peu, comment la programmation fonctionnelle peut donner les mêmes avantages qu’avec les types, comme du TDD en tests. C’était un talk vachement intéressant et moi qui aie un grand attrait pour la programmation fonctionnelle, j’ai beaucoup appris de ce talk et des langages fonctionnels. Comme le F# par exemple.
César : Justement, j’allais en parler un peu après *rire*. Le F# c’est un sujet assez tendance, on avait fait un meetup là-dessus puisque l’on n’a pas mal de personne de chez nous qui en font aussi. C’est vrai que c’est peu proposé par les clients ou en mission, notamment à cause des contraintes que j’évoquais dans d’autres podcasts. En revenant chez Veepee, dans quel cadre est-ce que cette entreprise te propose d’en faire ? Comment tu le mets en place et qu’est-ce que tu constates ?
Radwane : Alors, je n’ai pas amené l’approche fonctionnelle chez Veepee. Ce sont des personnes qui ont mis en place un premier projet en fonctionnel. Et je crois qu’un des premiers projets était en SQL, donc encore plus rare.
César : Pour avoir l’info là-dessus, est-ce que tu as l’historique de la démarche qui a fait que tout cela s’est mis en place dans une grande boîte ? En général, les équipes s’amusent à expérimenter des choses, donc qu’est-ce qui a fait qu’à un moment donné, il y a eu cette liberté de prendre le risque ? D’aller vers une techno sur laquelle personne n’avait travaillé dessus.
Radwane : Bien sûr, il y a toujours un risque quand on lance une telle approche. Après c’était dans une logique de transformation de Veepee. Donc il y a eu un effort de recrutement, avec l’arrivée d’un CTO et d’un Veepee Engineering, et ils avaient cette volonté de créer une communauté tech. Ils sont arrivés avec cette idée de créer des produits autonomes, avec des lead devs qui ont inculqué ce mouvement. Puis on a remarqué que ce langage fonctionnel attirait beaucoup de gens, et donc le recrutement s’est fait très rapidement. Au final, c’était un argument de vente pour intégrer Veepee, parce qu’on pouvait choisir les technologies que l’on voulait.
César : Je rajoute que si cette équipe a rapidement été recrutée, c’est parce que ces gens bossent sur d’autres technos en plus et qui sont donc assez passionnés et costaud d’un point de vue technique.
Radwane : Oui tout à fait. Et en plus, ce sont des gens qui sont assez actifs dans leur communauté. Donc même si on est nombreux, beaucoup de gens se connaissent et voir qu’un ami est recruté dans telle ou telle boîte, cela attire forcément. Et c’est ce qui a fait que je suis revenu chez Veepee. J’ai des amis qui soit, y étaient, soit y retournaient. Forcément, cela créer de la curiosité. Après, Veepee avait fait pas mal de meetups et de sponsoring, bien que plusieurs entreprises fassent pareil. Je me rappelle chez la Société Générale, il y avait des gens qui étaient passionnés par la communauté technique, et l’entreprise les pousse à faire du sponsoring, des meetups, des conférences, etc. Ce n’est pas toujours une stratégie très claire de l’entreprise, c’est principalement des gens passionnés qui font l’effort de partager leurs connaissances.
César : Et justement, toi dans un contexte de prod, en faisant du F#, comment est-ce que cela se passe dans l’équipe du point de vue prod, par rapport à l’image que tu en as ?
Radwane : Au départ, je suis dans une équipe qui ne connaît pas vraiment les langages fonctionnels. Et comme je peux en parler de manière excessive *rire*, nous en avons beaucoup parlé. On a fait quelques démonstrations et recherches, et l’équipe, d’elle-même, avait proposé que l’on fasse un projet dans ces technos. Et moi, je ne suis pas quelqu’un qui aime apprendre en prod ELM. Je leur ai dit, si vous voulez approfondir vos connaissances dans ce domaine et que le projet fonctionne, pourquoi pas.
Et c’est ce qui s’est fait, même plutôt facilement. Comme il y a une petite communauté Elm chez nous, avec Théophile qui organise des meetups et des katas entre midi et deux, ça a créé un engouement. Les gens commençaient à mieux en comprendre et à avoir moins peur de l’utiliser. Comme Elm est un langage qui tourne avec Java, c’est le même socle que l’on utilise. Au final, d’un point de vue prod, ça ne change pas grand-chose.
César : Et au-delà du paradigme sur la techno elle-même, quels étaient les avantages ?
Radwane : On l’a vu très vite, avec du Elm en front, donc assez strict, et d’un côté back, du Java. On a fait remonter le fait que ce soit bizarre d’avoir un code plus robuste en front qu’en back. Il y avait un module où il y avait une sorte de moteur de règle, et je trouvais que c’était dommage de ne pas le faire dans un langage fonctionnel. Enfin, je trouve que Elm et F# sont assez similaires. Et donc à l’époque, avec le développeur, je lui ai fait voir les similitudes et lui ai fait faire expérimenter plein de choses. Au final pour lui, la transition s’est faite beaucoup plus rapidement et plus simplement.
César : Mais justement, tu disais quelque chose qui a du sens. C’est-à-dire qu’il faut associer à un langage fonctionnel en front, un autre langage. Et si tu devais convaincre un responsable ou autre, de passer sur du F#, Elm et plutôt de la programmation fonctionnelle, quels seraient tes arguments ?
Radwane : Pour moi, les arguments pro langage fonctionnel c’est plutôt que ça compile et que ça fonctionne et que c’est super agréable à utiliser. Finalement, on perd une certaine verbosité et un risque que l’on pouvait trouver, et qui est lié au langage en lui-même. Java, c’est un langage que j’aime détester. Il a une communauté formidable mais d’un autre côté, c’est un langage tellement permissif. Il est enclin à produire des erreurs, et si on le met en parallèle, on voit pas mal de gain sur ce qu’offre F# ou Elm.
César : Oui, d’où le terme plus strict, qui te cadre un peu plus dans la qualité et où tu évites les erreurs.
Radwane : C’est ça, et puis on en a parlé rapidement, du Test Driven Development, mais quand on a un système de ce type, qui nous permet des modélisations intéressantes dans le domaine. Pour voir quel est l’outil de modélisation le plus intuitif et plus puissant. Je n’essaye pas de convaincre, mais les gens qui le vantent doivent d’abord être satisfait eux-mêmes de ce produit et savoir le maîtriser. Après il faut garder une cohérence dans la continuité en entreprise. Si tu es le seul à faire ce choix, tu peux amener un certain danger dans l’entreprise. Il faut trouver un équilibre entre l’expérimentation et l’utilisation, apporter une valeur à l’entreprise tout en évitant de faire de la tech pour la tech. Il ne faut pas non plus faire des choix complètement exotiques, qui ne correspondent pas à l’entreprise.
César : Je vois, tu as totalement raison. Je prends un exemple qui me vient en tête, où un de nos développeurs chez un client a dû utiliser pour un framwork front, du Aurélia. L’équipe s’y est donc mise mais c’était très compliqué pour eux de pouvoir recruter, et donc une plus grosse contrainte qu’autre chose. Ils ont eu du mal à recruter parce que la communauté n’était pas très importante et cela les a conduits à se séparer de ce framework pour passer à du React. Et il faut donc faire ce choix, du côté expérimental, et la capacité des équipes, à pouvoir suivre derrière.
Radwane : Exactement. Aujourd’hui, cela peut être un argument de recrutement, parce qu’il y a de plus en plus de personne qui souhaitent faire du fonctionnel. Donc on arrive à recruter des gens avec ça, tout comme avec l’argument du full-remote. Dans un contexte concurrentiel, les bons développeurs ont énormément de choix, donc il faut mettre en avant ces arguments. Il faut que dans une entreprise il y ait une certaine cohérence, des choix pragmatiques et mures. Un réel équilibre. Il y a tellement de projets qui ont été réécrit parce que l’équipe a changé et les technos aussi. Il faut donc minimiser les risques.
César : Il faut que ce soit des choix construits et pas des plaisirs de diva si on peut dire, que ce soit vraiment une dynamique. C’est aussi pour ouvrir la voie à d’autres talents que l’on ne connaît pas forcément. J’ai envie de remonter un peu le fil, et de savoir ce qui t’as poussé à partir à New York pendant un peu plus de deux ans. Et de savoir comment se passe la tech de l’autre côté de l’océan.
Radwane : C’est d’abord une volonté d’avoir cette expérience à l’étranger, dans un pays anglo-saxon. La culture tech de là-bas nous fascine un peu plus, il y a beaucoup d’a priori et de croyances sur comment cela se passe aux États-Unis. Donc c’était d’abord un choix personnel. Principalement parce que je n’étais pas satisfait de mon niveau d’anglais de l’époque, et que la meilleure façon de progresser c’est d’aller sur le terrain.
César : Oui c’est un peu comme lancer une conférence sur un sujet que tu ne connais pas bien.
Radwane : Exactement, et les premières semaines ont été un peu difficiles. Ils parlent très vite *rire* mais ça a été très intéressant. On est confronté à une autre manière de travailler, et on rencontre une nouvelle communauté tech. J’avoue que pour la Silicon Valley, on a une idée assez claire de la situation, mais pour New York, je ne voyais pas ce qu’était. Je pense être arrivé dans une époque de transition, où énormément de boîte de tech s’installaient, comme Google ou Facebook. Par exemple, un des premiers meetups auquel j’ai participé, c’était avec 150 personnes. Aussi, les conditions de travail des développeurs ne sont pas les mêmes, bien qu’on les voie arriver en France.
César : Et autour des bonnes pratiques, tu dis qu’il y avait une communauté, est-ce que tu les sentais stimulants, en recherche ? Quelle est l’image que tu en as ressorti ? Aussi, tu parlais d’une période de transition. Pourquoi cela ? Beaucoup de boîtes venaient à NYC et il y avait une émulation côté techno, ou bien c’était pour les bonnes pratiques ?
Radwane : Eh bien, en termes de bonnes pratiques, je trouve qu’il y en avait moins. Il y a une très forte communauté tech, mais pas forcément liée aux bonnes pratiques. Il y a un côté très pragmatique des Américains, donc c’était plus tourné vers les outils et le fonctionnel. Je n’ai pas vu de communauté Craft par exemple.
César : Je vois. Et c’est à ce moment-là que tu te poses la question, de soit rester à New York, soit tu savais déjà que c’était une expérience de passage ? Tu te laissais porter par l’expérience ou tu venais dans un but précis ?
Radwane : Je suis venu aux États-Unis par mon entreprise. Mais comme je voulais changer, j’avais candidaté et j’ai pu avoir un process avec une grande boîte. Sauf que je devais rester sur place un ou deux ans. Sauf que je ne me voyais pas rester si longtemps. Il y avait une procédure liée au visa, il y a des quotas là-bas. Et comme mon visa n’est pas transférable, c’était complexe. Donc ils me proposaient de rester autant de temps, mais j’étais incapable de me projeter. Avec du recul, j’aurai aimé faire une expérience de plus. Mais attendre deux ans, voire même plus, ce n’est pas ce que je me voyais faire.
César : Oui donc il y avait cette forme d’incertitude. Après, tu reviens en France chez Veepee, dans tout ce qui est fonctionnel. Comment se fait cette transition autour de l’architecture ? C’était dans un plan de carrière ou une évolution naturelle ?
Radwane : Je ne sais pas s’il y avait une logique, mais j’ai toujours voulu explorer les autres facettes de la tech. Mon obsession c’est d’avoir de l’impact, et c’est peut-être ça qui m’a motivé à être Architecte. Essayer de voir comment une équipe peut évoluer à partir d’un statut quo, de changer sa mentalité, etc. Et je pense que le coaching pour moi, a été un enrichissement pour moi. À la Société Générale, j’ai pu avoir cette approche un peu plus transverse. Il faut avoir un peu plus de patience pour influencer les gens. Aujourd’hui, je suis arrivée à un rôle d’architecte, pour voir comment on peut avoir un impact sans être celui qui écrit le code. Essayer de trouver un sens à ce que tout cela fonctionne.
César : Justement aujourd’hui, beaucoup de personne parlent de microservices, de Domain Driven Design, etc. Est-ce que c’est ce rôle-là, de conceptualiser toute une architecture dans l’entreprise qui soit cohérente, qui te permettent dans une équipe, de proposer de nouvelles choses. Quelle est ton approche par rapport à tout ça ?
Visuel ArticlesRadwane : Alors toi, tu parles de la partie implémentation de Domain Driven Design, qui est forcément intéressante. Mais oui, en tant que rôle transverse, on peut avoir de l’impact sur comment on implémente. Je trouve qu’il y a une discussion à avoir en amont dans le Domain Driven Design. C’est celle de comprendre le problème. Éviter ce micmac entre le flux vu par le business, et le process d’implémentation dans les outils. Je trouve que beaucoup d’entreprises ont ce problème, d’exprimer ce qui coince, d’avoir énormément de dépendance et ou d’interlocuteurs, etc. Et c’est ça qu’il faut éviter.
César : Ce que tu veux dire, c’est d’être moins dans le concret de l’implémentation, de la méthodologie, des patterns, etc. Il faut avoir une réelle transition entre le business et les équipes technique, pour que tout soit clair.
Radwane : Oui tout à fait. C’est justement sur la partie stratégique que l’on commence à implémenter. Mais aujourd’hui, on essaye d’avoir des Lead Dev, et des équipes qui soient fortes dans les bonnes pratiques. Parce que quel que soit le rôle transverse, au final, il faut essayer de ne pas devenir trop oppressant. Il vaut mieux que les gens design eux-mêmes, leur solution plutôt qu’une meilleure, mais sans savoir l’implémenter.
César : Oui bien sûr, pour que ce soit cohérent pour eux, sinon c’est de l’over engineering. Eh bien Radwane, merci beaucoup. Avant de conclure, aurais-tu deux trois recommandations de livre ou meetup ?
Donc bon, c’est qu
Radwane : J’espère le retour des conférences, je trouve que c’est un espace incroyable dédié à l’apprentissage et à l’échange. On a notamment les NCrafts, Devoxx, le Domain Driven Design Forum. Et en termes de livres, il y a pas mal de choses intéressantes. Elles sont plus liées à la partie fonctionnelle, avec le livre Domain Modeling Made Functional, de Scott Wlashin.
César : Eh bien Radwane, merci pour ton temps. Je pense que l’on a pu échanger sur pas mal de sujets ! J’espère que les gens pourront profiter un peu plus de ton expérience.
Radwane : Merci beaucoup, merci à toi César de m’avoir invité, et à très vite !
Retrouvez nos Podcast :
