Où va le Software Craft en 2023 ?

Rétrospective de deux jours à la NewCrafts conference avec Edwyn Tech

L’effervescence de ces deux jours de conférences vient de s’achever et je profite de mon trajet de retour en train pour en dresser le bilan. Ce fut pour moi une expérience à la fois riche et nouvelle car c’est le premier évènement de ce type auquel je participe à la fois au sein d’Edwyn Tech, sponsor de l’évènement, mais également en tant que développeur.

Une édition marquée par l’inclusion et la diversité

La première chose qui m’a agréablement surpris avant même de passer les portes du bâtiment c’est la diversité de genre parmi les oratrices et orateurs.

On retrouve cela sur place parmi les spectatrices où de nombreuses développeuses et personnalités féminines de la tech étaient présentes, jusqu’aux femmes enceintes de chez Shodo sur les stands des sponsors.

Bref, l’implication des organisateurs et de ses partenaires Ladies of Code et Duchesse France pour la présence des femmes était palpable.

Implication pour l’inclusion ne s’est d’ailleurs pas arrêté là puisque chaque participant·e a pu choisir le pronom à afficher sur son badge, demander le soutien d’un Conference Buddy ou encore manger des plats végétariens, végétalien et sans gluten.

Je suis fier d’évoluer dans un écosystème qui s’ouvre de plus en plus et qui travaille activement à combler ses lacunes. Ce n’est pas parfait mais on part de tellement loin… il faut bien célébrer chaque petite victoire, non ?

Une conférence d’ouverture qui rappelle les fondamentaux

Pendant longtemps nous avons fait des logiciels comme nous faisions des ponts : il nous fallait énormément d’études et de conception en amont de la réalisation pour prévoir tous les cas de figure et éviter d’avoir à refaire en cas d’erreur.

Parce que le code – quand il était bas niveau et très lié au matériel sur lequel on codait – ne se changeait pas comme ça, à l’instar des piliers d’un pont qu’on ne déplace pas facilement une fois en place.

Mais, ce que Dave Farley nous explique c’est que l’ingénierie logicielle moderne a changé la donne : le logiciel n’est plus un domaine comparable aux autres domaines d’ingénierie.

Je fais le rapprochement avec l’étymologie du mot « software », un mot qui nous est arrivé en opposition du mot « hardware » qui représente le matériel, ce qui est « dur », qui ne change pas.

Le « software » est la partie malléable de la machine, c’est celle qui nous permet de la reprogrammer pour une usage différent de celui pour laquelle elle a été construite à la base. Il n’y a plus lieu de tout concevoir en amont – et d’ailleurs les systèmes sont devenus si complexes qu’on ne peut pas – l’essence du logiciel est justement de pouvoir être modifié facilement et c’est ce qui le différencie des autres domaines d’ingénierie.

La conclusion de Dave est claire : « notre rôle en tant que développeur est de concevoir des logiciels que l’on peut faire évoluer facilement ».

Ça peut paraître un peu simpliste et donner l’impression d’enfoncer des portes ouvertes dit comme ça, mais je pense qu’il est important de rappeler qu’aujourd’hui en 2023 :

• il est plus simple de réécrire que de modifier une « Big Ball of Mud » ;
• nous changeons nos téléphones parce que les mises à jour successives les font ramer ;
• nous changeons nos ordinateurs parce que la nouvelle version du système d’exploitation n’est plus compatible avec notre processeur.

Bref, nous vivons dans un monde où le logiciel est devenu la partie rigide de la machine, à nous de changer cela !

Mais peut-on encore faire autrement ?

Aral Balkan se rappelle de son premier « Hello World », un programme de seulement quelques lignes dans un fichier unique. Aujourd’hui, un « Hello World » avec un framework comme NextJS c’est entre 400 et 600 Mo de données téléchargées et des milliers de fichiers.

Qui a mangé la simplicité ?

Cette conférence est je crois mon gros coup de cœur de NewCrafts 2023 tant la vision que nous a partagé Aral est alignée avec mes valeurs. Le Web avec un grand « W » est devenu le paradis du capitalisme de surveillance, entièrement contrôlé par les milliardaires de la Silicon Valley et leurs entreprises.

Ce paradigme s’étend jusqu’aux outils que nous utilisons au quotidien pour construire le web. Comment sommes-nous censés faire autrement dans ce contexte ? La réponse est simple : changer d’état d’esprit et d’outils.

Imaginez un monde où au lieu de louer un petit bout d’espace dans un système centralisé – souvent en échange de la violation de votre privée et droits fondamentaux – vous aviez votre propre espace à vous, rien qu’à vous, que vous contrôliez vous-même ?

Bienvenue dans le « Small Web ».

Mais pour contrôler son espace, avoir un site et un serveur à soi, c’est tout sauf simple avec les outils actuels qui sont conçus avec la logique des « Big Techs ».

C’est là qu’intervient « Kitten », l’outil qu’a développé Aral.

Kitten est une plateforme qui utilise nos vieux HTML, CSS et JavaScript sans fioritures. Pas de JSX, de préprocesseurs, de web bundler, juste un environnement d’exécution basé sur NodeJS dans un binaire unique qui tourne sur Linux, MacOS (et bientôt Windows).

Pas de compilation, développement aisé avec rechargement automatique, génération automatique de certificats TLS, un support natif de JSDB (une base de données JavaScript simplissime) et un système de chiffrement qui rend trivial les échanges sécurisés.

Son objectif ? Rendre le « Small Web » plus accessible avec des approches et outils fondamentalement autres.

J’ai hâte de tester Kitten pour de vrai. Je suis fatigué de la complexité des frameworks JavaScript et de leur guéguerre perpétuelles. Parce que pour utiliser les frameworks, il y a du monde, mais quand il s’agit de découpler son code et de faire des architectures évolutives, il n’y a plus personne.

Je ressens vraiment ce qu’Aral exprime : ces frameworks créés par des Big Tech font tout pour enfermer les gens dans un écosystème, avec une façon de faire, une pensée unique. Par exemple, React ne supporte toujours pas pleinement les Web Components, un standard du web. Et il suffit de voir la tronche que fait un développeur React quand tu lui parles d’injection de dépendances pour comprendre que les logiciels évolutifs de Dave Farley ne viendront pas de là.

Explorer des concepts radicalement différents est devenu une nécessité qu’on ne peut plus ignorer et ce genre d’initiative est une bouffée d’oxygène dont notre écosystème a clairement besoin.

Le logiciel, une affaire d’ascenseur ?

Imaginez les bureaux d’une entreprise qui serait dans une tour.

Les décideurs et parties prenantes sont tout en haut, dans l’appartement avec terrasse (le fameux « Penthouse ») et l’équipe qui construit le logiciel tout en bas, probablement même au sous-sol, pas loin du parking.

Cette image humoristique et un peu provocatrice met le doigt sur la distance qui sépare bien trop souvent ceux qui décident de ceux qui font. Comment rapprocher ces deux mondes ?

C’est la thèse de Michael Plöd dans sa conférence « Riding the elevator : Domain-driven Design in the Penthouse » : il suffit de prendre l’ascenseur.

Il est primordial que les parties prenantes aient de l’intérêt et comprennent ce qu’il se passe dans l’équipe de développement et le plus simple est d’aller leur parler directement.

Michael nous explique comment les outils du Domain Driven Design porté par l’équipe de développement, notamment la classification des domaines en tant que « core », « supporting » et « generic », aident aux décisions stratégiques de l’entreprise historiquement prises dans le Penthouse.

Les domaines « core », qui constituent l’élément différenciant de l’entreprise doivent systématiquement être développés en interne. Sous prétexte que l’entreprise n’est pas un éditeur de logiciel, beaucoup partent du principe qu’ils faut sous-traiter. On n’externalise pas ce qui est critique pour le business, pourquoi le fait-on pour le logiciel qui sert ces besoins critiques ?

Les domaines « supporting » peuvent être sous-traités avec un logiciel sur étagère personnalisable, un SaaS avec des extensions ou être écrits en interne s’ils ne sont pas très complexes.

Les domaines « generic », eux, peuvent être entièrement externalisés, ils ne représentent aucune valeur compétitive pour l’entreprise et sont interchangeables, les meilleures ressources de l’entreprise ne doivent pas être gaspillées ici.

Ces exemples montrent à quel point l’architecture logicielle est profondément intriquée avec la structure organisationnelle dans laquelle elle évolue et ne peut être construite indépendamment.

Le temps du logiciel construit dans une cave est révolu

Nick Tune est la personne qui m’a initié au Domain Driven Design via son livre qu’il a co-écrit « Patterns, Principles, and Practices of Domain-Driven Design », livre qu’il nous défend d’acheter pendant sa présentation !

Quand je lui ai demandé pourquoi pendant la session de questions / réponses, il m’a répondu « si vous achetez l’ancien vous n’allez probablement pas acheter le nouveau ». Pour ceux qui apprécient son humour, il a un nouveau livre « Architecture Modernization » (ceci n’est pas un lien affilié) qui va sortir d’ici fin 2023 et dont les pré-commandes sont ouvertes.

Tout ça pour dire que, et ça rejoint le discours de Michael Plöd, le problème du Domain Driven Design est qu’il a beaucoup été considéré comme un ensemble de pratiques d’ingénierie logicielle. Ce qui est faux, puisque c’est avant tout une philosophie de travail faite pour rapprocher le logiciel du business. Toujours est-il que dans la pratique, ça ne sort que rarement de l’équipe de développement, ce qui est contre-productif.

Mais ça les pratiquants avancés du DDD le savent et luttent déjà férocement pour impliquer le métier dans la modalisation du domaine. La nouvelle notion que Nick apporte ici est celle qu’il nomme les « Independant Value Stream ».

L’essence du DDD est d’aligner le code avec le business, l’essence du business est d’apporter de la valeur. L’idée ici est d’aller un cran plus loin et de créer une chaîne de valeur complètement indépendante au sein de l’équipe de développement.

Cela se résume en quatre étapes :

• Modéliser le domaine métier
• Définir un objectif de valeur mesurable
• Architecturer et implémenter le code
• Déployer la valeur en production et en assurer le support

C’est le flux de changement d’une itération que l’on va pouvoir répéter. Habituellement, l’équipe de développement n’est responsable que du numéro 3. Le numéro 1 ce sont les responsables produit, le 2 les parties prenantes / responsables projet, le 4 ceux qui s’occupent des serveurs avec l’équipe du support client.

Éventuellement on trouve les numéros 1 et 3 dans les équipes qui sont matures sur les pratiques du Domain Driven Design, mais ça s’arrête là.

Opérer ce changement est un chantier organisationnel important, il s’agit de ne plus considérer les développeurs comme des codeurs exécutants mais plutôt comme des vecteurs de développement de l’entreprise.

On me dit dans l’oreillette que c’est précisément ce à quoi fait référence le terme « développeur ».

Comme quoi, c’était dans le nom depuis le début ! Comment a-t-on fait pour passer à côté ?

Construire une architecture technique avec des gens

D’accord, le logiciel se fait avec des gens, il faut qu’ils soient alignés, autonomes, responsables, gnagnagna. Mais CONCRÈTEMENT, on fait comment ?

C’est la question à laquelle répond superbement Andrea Magnorsky. La qualité de l’architecture logicielle va dépendre de la capacité de l’entreprise à partager la connaissance.

On a tous connu ce moment où la personne qui sait n’est pas là et on doit se débrouiller sans elle. Ce moment où les développeurs qui n’ont rien bité au schéma d’architecture fourni par les architectes et décident d’arranger le truc à leur sauce pour livrer dans les temps. Ce moment où on se rend compte une fois la fonctionnalité livrée – et complètement boguée – qu’une petite session de conception en amont aurait été préférable.

Pour tout ça, Andrea a mis un point un format d’atelier qu’elle nomme Bytesize Architecture Session.

C’est un format court, de 45 à 90 minutes constitué de quatre étapes.

La première c’est d’expliciter le but de la session en 5 minutes. Par exemple : Quelle fonctionnalité veut-on architecturer ? Quel problème de performance veut-on solutionner ?

Ensuite, les participantes et participants vont travailler sur un schéma d’architecture chacun de leurs côtés (Andrea recommande l’outil de modélisation C4) puis vont présenter et débattre chacune des solutions entre pairs dans le but de faire émerger la meilleure. Cette partie doit durer maximum 10 minutes.

On passe ensuite à un phase de « consensus » pendant 20 à 30 minutes où on réalise un schéma commun constitué de la connaissance combinée de l’équipe.

La dernière étape dure quelques minutes et sert à récolter des retours sur l’atelier en lui-même : Qu’avons-nous accompli ? Que reste-t-il à faire ?

Le but de ce format est de pouvoir le répéter et itérer le plus souvent possible. La solution trouvé à chaque consensus n’a pas nécessairement besoin d’être satisfaisante ni parfaite mais peut simplement constituer une étape de réflexion pour permettre de creuser encore plus loin lors d’une prochaine session.

Il s’agit vraiment ici d’utiliser et de valoriser l’intelligence collective.

C’est un point sur lequel je suis profondément convaincu : de toutes les sections de conception ou de modélisation que j’ai pu faire à plusieurs dans mon travail, nous en sommes toujours sortis avec une solution plus pertinente que celles qui avaient été imaginées indépendamment.

Combien de fois me suis-je dit en sortant d’une de ces sessions que si je m’étais lancé avec mon idée telle quelle, le résultat aurait été d’une qualité tellement inférieure. En tout cas, je range consciencieusement dans un coin ce format d’atelier que je compte bien essayer à la première occasion !

Enfin, on s’amuse, on s’amuse, mais il va quand même être temps de conclure et de répondre à notre question : où va le Software Craft en 2023 ?

Apprendre de notre histoire

C’est la dernière conférence à laquelle j’ai assisté (je n’ai pas pu voir Kent Beck, retour en train oblige) mais je trouve qu’elle a parfaitement clôturé mon périple.

Cyrille Martraire nous retrace ici l’histoire du Software Craft, qui comme il l’indique, a perdu son « manship ». Comme je le disais en introduction, l’écosystème s’est emparé du sujet et il n’est plus question d’exclure les femmes avec un terme qui appartient au passé (même si, nous sommes d’accord, il y a encore du progrès à faire).

(Ceux qui ont envie de répondre que « craftsman » c’est un terme non genré en anglais et que « man » fait référence à « human » et pas au sexe masculin, sachez que c’est une gymnastique que notre inconscient ne fait pas et puis à partir du moment où nous avons un terme plus court, qui lève l’ambiguïté, qui sommes-nous pour ne pas l’utiliser ?)

L’évolution dans le temps, c’est en fait l’entièreté du sujet ! Le Domain Driven Design, le TDD et l’agilité sont des concepts vieux de 20 ans mais qui commencent seulement à être pleinement démocratisés.

A l’instar de certains psychanalystes avec Freud, certains vouent un culte aux écrits de leur gourou préféré. L’un des enjeux de notre époque est de moins s’attacher aux détails qu’au discours de fond et de l’adapter en permanence aux nouveautés de notre quotidien.

Ceci étant dit, s’il y a bien une chose à reprendre tel quel selon Cyrille, ce sont les principes de l’eXtreme Programming (XP) qui viennent solutionner bon nombre des problèmes que nous rencontrons avec SAFe et Scrum dans le développement moderne et je suis bien d’accord avec lui.

Ce qu’il faut retenir en définitive, c’est que nos systèmes d’information sont bien moins techniques qu’on ne le pense et qu’il est temps de remettre l’humain au cœur de la technologie et des logiciels.

Après tout, la technologie n’est-elle pas faite pour être au service des personnes ?

C’est, je pense, ce que montre cet article et ces conférences et j’ai le sentiment qu’on avance dans le bon sens. Certes il ne s’agit pas là d’une synthèse exhaustive (je n’ai pas pu assister à toutes les conférences) ni d’un discours qui n’est pas orienté par mon prisme de lecture (mais après tout, c’est moi qui écris alors je fais ce que je veux !) mais je vois quand même un fil conducteur entre Dave, Aral, Michael, Nick, Andrea et Cyrille.

Embrasser le changement, construire pour les personnes, en prenant la peine d’aller leur parler, en étant responsables et autonomes, avec des méthodes qui prônent l’intelligence collective, avec l’intelligence émotionnelle pour tirer les enseignements de notre histoire et se préparer à l’avenir.

Le vois-tu ?

Un événement sponsorisé par Edwyn Tech

Je ne peux décemment pas terminer cet article sans mentionner ceux qui m’ont permis d’assister à ces conférences en premier lieu ! Michael et Vincent sont les deux gugusses qui dirigent la barque chez Edwyn Tech, une ESN 100 % Craft basée sur la transparence, l’équité et le soucis du collaborateur.

Oui, je sais, dis comme ça, ça fait hyper bateau, c’est le discours que balance n’importe quel commercial qui chasse du gibier sur LinkedIn.

A vrai dire, si Vincent m’avait contacté directement il y a un an, je lui aurais gentiment répondu que je n’étais pas intéressé par le modèle des agences et des ESN. Il a fallu qu’on soit mis en relation par une intermédiaire (coucou Camille) pour que j’accepte de leur parler et que je sois finalement convaincu !

Si je résume en deux mots, le concept est simple : que des développeurs expérimentés (même si on a un programme dans les tuyaux pour accompagner les juniors), uniquement des missions longues (de 1 à 3 ans) orientées Software Craft (jamais un client ne te demandera de sauter l’étape des tests pour « aller plus vite ») et une profonde transparence.

Ici on oublie l’angoisse de la négociation du salaire à la fin de l’année, tout le monde est logé à la même enseigne, ton salaire brut dépend de ton nombre d’années d’expérience et est revalorisé automatiquement chaque année : https://www.edwyn.tech/notre-modele.

En plus de ça, nous disposons d’une rémunération variable conséquente pour piloter individuellement nos avantages salariés, des séminaires toutes les 6 semaines avec des bonnes bouffes, des projets internes rémunérés en fonction de l’impact pour l’entreprise, des participations à des conférences comme ici pour faire connaître le modèle et développer nos expertises.

Bref, j’arrête ici la pub, mon train vient de me déposer dans ma campagne profonde et il est temps pour moi de me remettre des mes émotions autour d’un apéro au bord de l’eau !

Si des contenus tech comme celui-ci t’intéressent, n’hésite pas à suivre Edwyn Tech sur LinkedIn.

A plus !