Bonjour Sallah, peux-tu te présenter en quelques lignes  ?

Bonjour, je suis ingénieur informaticien, passionné de technologie et de code bien fait. Outre mes années d’amateur du code (collège, lycée, école d’ingénieur), j’ai 14 années d’expérience principalement en France entre Sophia-Antipolis et Paris. J’ai aussi eu l’occasion de travailler en Californie (Palo Alto) et en Angleterre (Londres). Ces dernières années, depuis le Maroc (Casablanca), j’accompagne des entreprises en Afrique et au Moyen-Orient dans le cadre de programmes de refonte digitale. Je les aide à mettre en place une organisation de delivery techniquement mature, à faire les bons choix techniques et technologiques pour soutenir leurs stratégies business, à réaliser les solutions logicielles leur permettant d’acquérir un avantage compétitif sur le marché.

 

À quel moment dans ta carrière as-tu découvert l’Extreme Programming (XP) et les pratiques associées ?

La première fois, ça devait être en école d’ingénieur. Mais j’en ai compris l’intérêt et la valeur ajoutée en milieu professionnel.

 

Qu’est-ce-que ça a changé dans ta perception du métier de développeur ?

Le sens du professionnalisme dans la réalisation de logiciels et la production de code! Il me semble après quelques années d’expérience que la connaissance de l’XP, et son application en contexte projet, est ce qui permet d’approcher l’implémentation d’un logiciel en tant que vrai professionnel du code. C’est l’un des frameworks méthodologiques qui se distingue du lot. Avec cette boîte à méthodes, si comprises, acceptées et adoptées par l’équipe, on se rend compte qu’il est possible de faire différemment, et ainsi produire un code plus facilement maintenable et extensible. 

Un code lisible avec lequel tous les membres de l’équipe se sentent à l’aise. Un peu comme une copropriété où il fait bon vivre pour les occupants. Un framework qui fournit une meilleure expérience de développement (DX) grâce à du code au comportement prédictible, ayant moins d’instabilités et nécessitant encore moins de consacrer des nuits blanches à essayer de trouver le “million dollar bug”. La méthode phare de l’XP c’est le TDD, soit Test Driven Development. À l’image de l’artisan, le développeur dispose de boîtes à outils qui lui permettent de bien faire, voire d’exceller.

 

La première fois que tu as découvert le concept de dette technique, et vécu son impact concret sur un projet, quel a été ton ressenti ?

L’étonnement, pour en avoir été personnellement contributeur.

Puis l’indifférence, pour ne pas avoir mesuré l’étendue de ma contribution, voire en minimisant son impact sur le déroulé des projets. Trouvant comme excuse, qu’au final, le logiciel avait été livré à temps, et avec l’ensemble des fonctionnalités demandées. Et s’il y a bien un métier où l’adage “il n’y a que le résultat qui compte” ne marche pas, c’est l’informatique.

Puis la fatigue, en compensant cela par des heures incalculables de travail, à tenter de  remédier aux problèmes apparents, tout en reproduisant les mêmes erreurs. Car au fond, la méthode ne changeait pas: “coder sans tests”. Et malheureusement, on ne résout pas un problème avec la logique qui l’a introduit. En effet, le TDD, par exemple, n’était pas à l’ordre du jour. 

Puis la colère, pour avoir réalisé que pour un ingénieur, j’ai passé plusieurs années à travailler techniquement comme un amateur.

Puis la curiosité, en discutant avec les communautés craftsmanship et d’autres praticiens qui ne jurent que par le TDD et autres bonnes pratiques de développement XP. 

Puis le plaisir, pour m’y être essayé sur des pet-projects. J’ai eu l’impression de ré-apprendre à coder. Le switch n’a pas été instantané, car les habitudes sont dures à changer. Toutefois, l’intérêt grandissait car j’ai pu apprécier la stabilité et la lisibilité du code produit, ce qui m’a donné envie de l’appliquer en entreprise.

Puis la fierté, en y prenant goût, en apprenant et influençant d’autres collègues à suivre les bonnes pratiques, en voyant l’impact technique et humain qui était à minima bénéfique pour la réduction, et la maîtrise à bas niveau, de la dette technique.

Toute entreprise souhaiterait produire des logiciels durables, sans bugs, avec un code et une architecture qui demeurent Clean au fil des années. Pourquoi est-ce si compliqué d’y arriver ?

Je vais tenter d’y répondre en me basant sur ce que j’ai pu apprécier de l’industrie logicielle sur ces dernières années en ayant travaillé auprès d’éditeurs multinationaux, de startups et acteurs non-techniques fournissant des services digitaux.

Une des raisons qui pourrait l’expliquer, c’est que ce ne soit pas l’un des principaux souhaits pour toutes les entreprises. 

Pour les éditeurs de logiciels, c’est indéniable, car il en va de la principale source de revenus pour l’entreprise. Pour les autres, dont le cœur de métier n’est pas l’informatique, le logiciel est un moyen plus ou moins important pour fournir leurs services et produits, idéalement via les canaux digitaux. Et dans d’autres cas, un moyen d’automatiser des tâches opérationnelles ou de prendre des décisions plus vite à l’aide de leur patrimoine de données.

Pour la première catégorie, c’est plus facile, elles y arrivent très bien car elles ciblent principalement des collaborateurs étant des professionnels du code et déploient un dispositif RH de fidélisation adéquat. Sur cette base, la culture d’ingénierie y est à son paroxysme avec des moyens technologiques de dernier cri pour rester compétitifs, avec certaines perles dont elles sont elles-mêmes à l’origine, que ce soit en tant que solutions propriétaires ou open-source. Dans ce type de cadre, il est généralement difficile pour un collaborateur de faire autrement que du code clean, de qualité et des architectures viables. Les développeurs y sont généralement considérés comme des first-class citizens.

Pour la seconde, c’est plus compliqué. Le code y est généralement perçu comme étant un moyen plutôt qu’un atout. On y retrouve un dispositif RH généraliste sans réelles incentives à l’entretien d’une culture d’ingénierie pour veiller à entretenir une vraie culture du code et une identité technique dans la durée. Les parcours de carrière y sont aussi orientés à long terme plus business que technique. Et on peut le comprendre, car du moment que ces institutions recrutent des ingénieurs, elles partent du principe que ceux-ci agiront en professionnels du code et produiront un logiciel de grande qualité. 

Pour elles, les collaborateurs veilleront à maintenir des architectures robustes. C’est là l’erreur, la culture d’ingénierie en entreprise doit être entretenue et récompensée, plutôt qu’être attendue et réprimandée en cas de manquement. Si la culture d’ingénierie n’est pas une priorité, la recrue en générale grandira en s’alignant sur les pratiques existantes, répliquant les mauvaises habitudes de ses pairs, entretenant la dette technique et en ayant des fois peu conscience de l’impact négatif créé. Dans ce contexte, les équipes sont généralement intéressées par le résultat à court terme, cherchent les raccourcis pour booster les délais de livraison, et malheureusement finissent par fournir des fonctionnalités au détriment de la qualité du code, avec dans les meilleurs des cas une dette technique connue et regrettée, et dans le pire connue et assumée. 

Dans un contexte comme dans l’autre, produire du code clean est considéré comme un acquis par les entreprises. Et c’est comment elles veillent à entretenir et valoriser cet acquis qui fait la différence.

Un des enjeux ces dernières années est de “scaler” l’Agilité à l’échelle dans les entreprises.

On a l’impression qu’aujourd’hui on cherche à faire la même chose avec le Software Craftsmanship, la qualité technique semblant avoir été quelque peu oubliée dans cette affaire.

Quel est ton regard là-dessus ?

En effet, l’Agile a bouleversé l’industrie logicielle et pendant longtemps les entreprises y ont vu une solution pour livrer plus vite tout en étant plus proches des utilisateurs finaux.

Mais, c’est en effet quand les entreprises veulent passer à l’échelle qu’elles se rendent compte des limites du système que j’ai décrit précédemment dans le second contexte d’entreprise. Certains décrivent cela comme étant l’Agile Hangover.

On l’aura compris, ce n’est pas tenable à l’échelle d’avoir des dettes techniques, une culture d’ingénierie approximative et une connaissance qui se dilue au gré du turn-over.

Le Software Craftsmanship est l’un, si ce n’est l’unique manifeste et mouvement communautaire, qui à ce jour vient combler un vide dans le triptyque : 

• Do the right thing: Agile
• Do the thing fast: DevOps
• Do the thing right: Craftsmanship

 

Quels furent pour toi les défis à relever quand tu as accompagné des équipes à gagner en excellence technique ? 

Le top 3 :

1. Les habitudes : Quand les équipes ont pris l’habitude depuis plusieurs projets à travailler en prenant des raccourcis, il devient dès lors très compliqué d’instaurer les bonnes pratiques. L’accompagnement au changement nécessite de faire preuve d’empathie, de répétition et d’humilité.  
2. Les sponsors : il est important de veiller à obtenir l’appui des équipes de direction et des managers. Certains n’étant pas techniques, on se retrouve à devoir sortir de sa zone de confort pour rallier les bonnes volontés et expliquer l’utilité du changement et de son bienfait sur les dimensions métiers et opérationnelles.  
3. Le temps : surtout le Time to Market. C’est une obsession pour tout business. Toutefois, la seule façon d’aller vite, c’est d’aller bien (dixit Robert C. Martin). Et c’est plus facile à dire qu’à faire entendre. Jongler entre vélocité et rigueur technique est un défi majeur au quotidien tant avec les développeurs, qu’avec les acteurs métiers.

Quel regard portent selon toi des personnes “non techniques” sur les valeurs du Craft ?   

Au premier abord, charabia et scepticisme 🙂 Plus sérieusement, les personnes non-techniques comprennent un langage et acceptent plus facilement des concepts non-techniques. Et, c’est tout à fait normal. Si vous allez voir un CEO d’entreprise, ayant un MBA et un bagage financier, lui dire on va faire du code de qualité comme le feraient les artisans, ça risque au mieux de l’amuser et au pire de l’ennuyer.

Mais si vous allez le voir en lui disant l’entreprise perd quelques millions par an à cause d’un manque de maturité technique et que la tendance marché est le Craftsmanship, là il va vous regarder et vous écouter tant que vous restez loin du jargon: TDD, BDD, Refactoring.. la même chose s’applique au DRH, aux managers non techniques et autres collaborateurs fonctionnels.

Après quelques itérations et à force d’en parler, on peut être agréablement surpris, car l’une des réactions c’est que ces valeurs pourraient s’appliquer à n’importe quel métier dès lors où l’on devient soucieux du savoir-faire et de la qualité de ce qu’on produit.

Qu’est-ce qui explique selon qu’une équipe n’éprouve pas d’appétence pour ces sujets et cette volonté d’améliorer leurs pratiques de développement ?   

À mon avis, pour que l’appétence se crée, il y a besoin que les 3 principaux acteurs y trouvent intérêt :

• Les individus : en premier lieu les développeurs, en réalisant que ça leur offre une meilleure expérience au quotidien et des débouchés plus intéressants à moyen-long termes.
• Les entreprises : en offrant un cadre de valorisation RH et opérationnel ciblant l’entretien des bonnes pratiques d’ingénierie.
• Les écoles: en revisitant le cursus scolaire et y encrant les valeurs craft et pratiques XP comme un ingrédient pédagogique central.

A ce jour, j’ai pu constater, dans l’industrie logicielle, des manquements auprès de chacun de ces acteurs.

Justement, comment initier cette appétence progressivement au sein d’une équipe ? Et quels sont les investissements nécessaires (temps, moyen, …) ? 

Il n’y pas de recette magique. Mais ce qui me vient le plus naturellement, commence par une prise de conscience par le management en fonction qu’il y a un problème et un intérêt business à y remédier. Dans un second temps, il est nécessaire d’instruire une politique d’entreprise basculant le logiciel de moyen à atout. Cette politique aura pour effet d’accorder les fonctions d’entreprise pour soutenir le développement des logiciels produits et non pas l’inverse. Et par conséquent, cette nouvelle politique touchera:

• Aux RH: recrutement, développement et rétention des talents 
• Aux Infrastructures : modernisation des usines de développement logiciels et environnement de run
• Aux Opérations: construitent autours des logiciels à produire

Concernant les moyens financiers et la durée utile à opérer le changement. Je dirais que ce n’est probablement pas le débat, c’est une entreprise “continue”, à mener tant que le business y voit retour sur investissement et avantage compétitif.

Au sein d’une organisation IT de plusieurs dizaines voire centaines de personnes, comment instaurer et pérenniser une culture proche des valeurs Craft ?

Il y a trois principaux ingrédients :

1. Un profil CTO, VP-Engineering, solide : il faut un chef d’orchestre qui comprend le craft et qui en voit la valeur ajoutée. Car c’est cet acteur qui va au quotidien convaincre et influencer l’organisation pour changer et maintenir le cap.
2. Une Guilde: un groupe de passionnés, non-hiérarchique, transverses à l’entreprise qui partagent un intérêt commun pour les bonnes pratiques et de se retrouver par moment pour pratiquer ensemble et communiquer à propos de leur craft.
3. Un investissement : il faut un minimum de moyens, d’espaces de partage/plénière, des pc de qualité connectables à internet :), des incentives RH (tickets conférence, ..), aménagement de temps.

On ressent aussi une prise de conscience croissante sur l’importance des “Soft skills” des développeurs et développeuses. Quel est selon toi le bon “Mindset” aujourd’hui quand on développe en équipe ?

C’est en effet indispensable, il ne suffit plus de savoir coder, il faut aussi savoir développer un bon relationnel et le manifeste du software craftsmanship et l’XP l’illustrent bien.

Quelques aptitudes clés :

• Egoless programming : mettre l’ego de côté pour porter la nature des débats autour du logiciel à fournir plutôt que sur des jugements de valeur.
• Courage : aller vers les autres et prendre position sur les bonnes pratiques de développement
• Empathie : se mettre à la place de l’autre, et je dirais même à la place du client. Sans cela, on ne peut accompagner le changement ou d’approcher d’une solution qui sera vraiment utile et à valeur ajoutée pour l’utilisateur final.

J’en parle en détail dans mon livre dans la partie réservée au savoir-être. Avoir la bonne attitude est l’ingrédient qui fait la différence dans le développement personnel, et qui bénéficie à toute l’équipe par effet domino.

A ces sujets, en termes d’attitude et d’état d’esprit, quels sont les écueils et problèmes récurrents que tu observes aujourd’hui ? 

La précipitation : Des entreprises en peine car elles veulent accélérer mais ne savent pas par quoi commencer et à quelle dose. Des collaborateurs qui veulent grandir vite en cherchant les raccourcis au détriment de la maîtrise de leur savoir-faire. Je dirais que c’est un des fléaux de notre génération économiquement mondialisée.

Le syndrome du codeur sauveur : les entreprises vont mettre en avant une intervention ponctuelle où un collaborateur se distingue en sauvant la situation. Ce qui en soit est une bonne chose. Mais des fois, c’est ce même codeur qui est à l’origine de la dette technique entretenue avec son équipe. Ça donne la douce illusion qu’il n’y a pas besoin d’un changement et qu’on pourra toujours s’en sortir par des interventions salutaires. Ce syndrome ne permet pas de passer à l’échelle. Idéalement, n’importe quel collaborateur de l’équipe pourrait sauver la situation si les bonnes pratiques sont appliquées et la connaissance partagée.

La peur : en effet, changer de méthode, de mode de fonctionnement c’est comme s’engager vers l’inconnu. C’est un risque à ce jour que peu de monde arrive à prendre. Surtout dans des cultures sociales ou d’entreprises, où l’erreur est perçue plus comme étant un défaut qu’une opportunité d’apprentissage

Tu parles de partage de connaissance et d’application des bonnes pratiques, c’est un sujet qui nous intéresse fortement chez Promyze.

Comment peut-on faire pour amener les personnes compétentes à partager, et celles qui en savent moins à recevoir cette connaissance ? 

Je te remercie pour la question, et pour cause, c’est un élément central du Software Craftsmanship dont je cite un extrait du manifeste: “relever le niveau du développement professionnel de logiciels par la pratique et en aidant les autres à acquérir le savoir-faire”. 

Avec cet élément introduit, je dirais qu’il est primordial d’avoir un mouvement fédérateur, qui permet de croiser les intérêts des uns et des autres autour de challenges et d’aspirations communes. Le Software Craftsmanship l’incarne parfaitement.

Si j’aurais une suggestion, ça serait celle de contribuer au développement et au renforcement de ces communautés en leur fournissant des moyens pour se connecter les unes aux autres, d’être encore plus visibles entre elles, de partager leur connaissances et pratiquer sur une plateforme commune. 

Je crois beaucoup aux cercles vertueux, et de contributions en contributions ça fournirait un cadre qui donnerait de plus en plus envie aux personnes expérimentées de partager et aux autres, proches ou éloignés géographiquement, de rejoindre, d’apprendre puis de contribuer à leur tour.

Qu’est-ce qui doit changer selon toi au sein des entreprises si elles veulent atteindre l’objectif initial dont on parlait, à savoir produire du code durable ? 

Sûrement une approche orientée valeur, plutôt qu’une approche orientée résultat. Et basculer vers la valorisation du ‘COMMENT’ (les méthodes, les pratiques, l’approche pour fournir le produit et service au client), en complément du ‘QUOI’ (le produit, le service que reçoit le client). A ce jour, le QUOI est généralement ROI. A titre d’exemple, l’Agile fortement adopté est plus focalisé sur le QUOI, alors que le Craftsmanship faiblement intégré est plus focalisé sur le COMMENT.

La découverte des pratiques de l’Extreme Programming est un sujet qui semble petit à petit trouver sa place dans les cursus pédagogiques. Quel est ton point de vue là-dessus ?

C’est très positif. À ma plus grande joie, Il y a de plus en plus d’initiatives pédagogiques qui inculquent les méthodes et valeurs de l’XP. Que ce soit des formations certifiantes pour les reconversions professionnelles, des introductions aux bonnes pratiques de code en entreprise ou des UVs TDD en milieu universitaire, la cadence semble s’accélérer. Vu l’accroissement de la consommation en solution digitale, les utilisateurs deviennent de plus en plus exigeants en termes de qualité de service logiciel. Car à deux produits aux fonctionnalités égales, ils préféreront celle ayant la meilleure qualité sous-jacente. Il ne suffit pas de fournir de beaux écrans, il faut que les performances en temps de réponse soient là, que les données soient sécurisées et que les interruptions de services soient quasi-inexistantes. Les prochaines années seront marquées par un renforcement des pratiques en milieu scolaire et en entreprise pour répondre à cette exigence du marché.

Tu as également eu l’occasion de découvrir Promyze récemment. Quels sont les atouts de la solution selon toi ?

J’aime beaucoup l’ADN. On trouve beaucoup de sociétés qui vont se concentrer sur de la prestation de service prônant le Craftsmanship mais rares sont celles qui proposent des solutions logicielles pour l’opérationnaliser. Promyze en est un parfait exemple. Le positionnement technologique est intéressant. J’aime beaucoup que la solution s’intègre à des outils du marché qui sont appréciés tant par les entreprises que les communautés de développement, je pense notamment à votre plugin sur Intellij IDEA ou votre intégration avec SonarQube. L’une des forces majeures que j’y vois aussi est l’interface qui favorise la création de bonnes pratiques de façon collaborative, ce qui permet aux équipes de s’approprier et personnaliser leur approche à la dette technique.

Un grand bravo !

Promyze propose des formats d’ateliers en équipe pour faire émerger ses bonnes pratiques. Quels autres rituels techniques peuvent être mis en place dans cette démarche d’amélioration continue ?

Je trouve ça très bien vu que ça insiste sur l’échange en équipe et veille ainsi à créer un sentiment de “collaborative ownership”, tels que le recommande l’XP. Dans la continuité, je verrai très bien un ensemble de Katas illustrant comment résoudre une dette technique avec des solutions types, pas-à-pas, mettant en avant des techniques telles que le TDD en synergie avec le Refactoring.

Tu as publié l’année dernière un livre sur le Software Craftsmanship. Peux-tu nous en dire davantage sur la genèse de ce projet ?

Tout a commencé par un programme de formation sur 3 semaines, au format bootcamp, que j’avais mis en place pour on-boarder 14 jeunes développeurs au sein d’un groupe bancaire. L’objectif était de les faire monter en compétences pour qu’ils puissent être opérationnels sur les projets digitaux de la banque. C’était une aventure merveilleuse tant humainement que techniquement. 

Un bootcamp qui nous a permis de travailler sur 4 axes:

• Savoir-être: La bonne attitude, les  soft-skills à adopter et cultiver
• Savoir-faire: les méthodes à pratiquer pour produire du code de qualité et les pièges à éviter concernant la dette technique
• Savoir structurer: les frameworks à connaître pour modéliser les problèmes et réflexes à avoir pour obtenir une architecture évolutive
• Savoir penser: développer une méthode de veille technologique et savoir identifier et suivre les influenceurs de bon goût

Au travers de ce cycle, j’ai réalisé que ce programme n’a pas seulement contribué à initier ces développeurs aux bonnes pratiques. Il leur a été fortement bénéfique en interactions humaines, créant un cadre de mentorship avec d’autres experts de l’entreprise qui leur ont partagé des retours d’expériences, un condensé de points d’attention en entreprise et les secrets de certaines méthodes qui nécessitent chacune la lecture d’ouvrages de plus de 500 pages. Je pense notamment au DDD d’Eric Evans. Le plus frappant étant que la majorité des notions abordées sont décrites en détails dans des ouvrages en anglais et des fois difficilement accessibles à une population francophone.

C’est ainsi que j’ai entamé la rédaction de mon livre, avec l’idée de partager les différences leçons apprises au cours de mes différentes années passées auprès de différents contextes d’entreprises. Je voulais rendre accessibles les différentes notions clés de l’industrie logicielle et parcourues pendant le bootcamp. Et enfin, donner goût et rendre accessible le craftsmanship à tous développeurs souhaitant progresser dans l’entreprise en tant que professionnels du code, et praticiens souhaitant mieux connaître cet univers.  

Software craftsmanship : l’art du code et de l’agilité technique en entreprise

Paru en 13/11/2019 chez ENI

Lien