Divers

Retour sur la conférence NewCrafts 2019 (1)

Mai 27, 2019

Eric FAUQUEMBERGUE

J’ai eu la chance d’assister, au nom de DCube, à la 6ème édition de la conférence NewCrafts, qui a eu lieu mi-mai à Paris. Je me propose de vous faire ici un compte rendu de cette conférence, en se concentrant sur la première journée pour ce qui est de cet article. Un deuxième article traitera du jour 2…

N’ayant pas pu assister à toutes les sessions car il y avait 4 parcours en parallèle, ce sera forcément partiel. Et ce sera aussi partial, car c’est une conférence qui, nous allons le voir, touche profondément le coeur et l’âme (si si) !

J’entretiens une relation particulière avec cette conférence, qui tient une place à part sur la scène des évènements IT; lorsque je me suis rendu à la première édition (sous le nom de nCrafts), j’avais eu une vague impression d’élitisme car le slogan de la conférence « raise the bar » était respecté : on y trouvait alors des sujets pointus autour la notion alors à la pointe de la hype de « craftmanship » (fierté d’être des artisans du code), traités par de grosses pointures intellectuelles de notre industrie. Cinq ans plus tard, la conférence a évolué vers l’introspection sur nos métiers et sur leurs aspects éthiques et politiques. On ne va pas à NewCrafts pour découvrir le dernier framework technique à la mode ou des séances de live coding, mais pour réflechir à notre manière de travailler et à son impact sur l’entreprise, ou plus globalement sur la société et les générations futures. Avec l’explosion de la Big Data, de l’IA, des GAFA, cette évolution des thématiques abordées est naturelle… et salutaire !

Voyons maintenant un résumé des meilleures sessions auxquelles j’ai assisté sur ces 2 jours. Ces sessions étant disponibles en video à la mi juin sur le site de la conférence, j’espère que ces quelques lignes vous inciteront à aller les regarder en replay. Je ne mentionnerai pas les ateliers auxquels j’ai participé mais qui ne seront pas rendus disponibles en replay.

Jour 1 – Intro

En introduction de cette journée, les organisateurs ont clairement planté le décor : nous exerçons notre métier dans un système global, où l’entreprise, que l’on doit voir comme un système vivant et complexe, cohabite avec ses concurrents, ses clients, les systèmes dont elle dépend, les processus législatifs et industriels dans lesquels elle s’inscrit, et les réseaux sociaux. Le savoir technologique n’est plus suffisant : on se doit de comprendre le système dans sa globalité pour trouver le sens de notre travail. C’est cette quête de sens qui est l’objet de la conférence.

C’est en questionnant nos pratiques, nos « soft skills », notre relation aux autres, l’attention que l’on porte à la qualité, notre rapport à l’éthique que cette quête de sens va se dérouler au long des séances de ces 2 jours de conférence.

Jour 1 – Keynote d’ouverture : « The one with the compiler always wins »

Le thèse de la keynote présentée par Ulrika Malmgren est d’expliquer que le développeur a le pouvoir, et qu’il doit par conséquence user en conscience de ce pouvoir.

Les arguments qui vont dans ce sens abondent : le développeur contrôle souvent le temps de par sa position sur le chemin critique d’un projet (dans la mesure où de nombreuses autres personnes doivent attendre la fin de son travail pour pouvoir travailler à leur tour), il décide de ce qui est possible techniquement ou pas (dans la mesure où les non-techniciens font confiance à son jugement sur le sujet), il décide de la qualité, de qui est au courant de tout ce que contient le logiciel produit (il peut ajouter une fonctionnalité de son propre chef). On voit aussi souvent des développeurs qui se sont rendus indispensables dans l’entreprise, et qui possède donc de facto un fraction importante de pouvoir.

Des contre arguments sont présentés pour être réfutés aussitôt : non ce n’est pas l’équipe qui décide (par peur des conflits, et par pression des pairs), non ce n’est pas le Product Owner qui décide (par peur de ne pas pouvoir produire si le développeur n’est pas d’accord), non ce n’est pas le manager qui décide (grâce aux techniques de « guerilla » mises en place pour contourner les décisions du management, et par surévaluation du pouvoir des managers).

Ensuite, il nous est rappelé que, si le développement est complexe, le métier de développeur serait assez doux : environnement de travail confortable (vs hôtesse de caisse), horaires flexibles (vs travail en usine), pas d’effort physique (vs BTP), pas de conséquences terribles en cas d’erreur individuelle (vs chirurgien), salaires élevés, le plus souvent amusant.

Mais cela ne doit pas nous faire oublier la notion de responsabilité. Un sondage édifiant est mentionné : si 49% des développeurs répondent qu’ils n’écriraient pas du code non éthique, 36% répondent qu’ils ne feraient peut-être.

Les 36% ne peuvent se réfugier derrière le paravent « c’est de la faute de mon manager si j’ai écrit du code non éthique » : l’ingénieur de Volkswagen qui a écrit le logiciel de trucage des émissions de gaz polluant et qui a été condamné à de la prison pourrait témoigner !

Pensons aussi aux « dark design patterns », ce code qui a été écrit par des développeurs dans le but de tromper les utilisateurs de site internet, récupérer leurs données personnelles à leur insu, les submerger de publicités, de pop up infernales et autres ransomware.

Au delà de ces arnaques écrites sciemment, tout un pan des technologies que l’on développe peut être détourné du côté obscur de l’éthique alors qu’elles ont été créées comme « neutres » : le bot de Microsoft devenu nazi, les algorithmes de recrutement d’Amazon qui refusent les femmes…

Nous vivons dans des démocraties en paix, mais que deviendront nos technologies dans un autre contexte ?

Le speaker nous rappelle donc à notre responsabilité à prendre de bonnes décisions avec le pouvoir (sous estimé) que nous avons.

Excellente keynote qui fait bien réflechir, donc !

Jour 1 – Session « Passions of Programming »

Dans cette session, Kevlin Henney aborde le sujet de la passion, en partant du constat que la plupart des offres d’emploi IT explique rechercher des « passionnés ».

Etymologiquement, la passion vient du mot souffrance, c’est un enthousiasme intense et difficilement contrôlable. Est ce vraiment ces sentiments que l’on souhaite injecter dans une équipe ? A l’inverse, l’absence de passion peut amener à l’indifférence, qui n’est pas forcément souhaitable non plus !

Le speaker enchaine alors sur l’humilité dont on doit faire preuve : le code est une représentation de connaissances qui peuvent être imparfaites et incohérentes, pas de la logique pure et infaillible !

Nous devons développer nos « soft skills » : capacité d’apprentissage, communication, négociation sociale, architecture (en tant que règles de participation dans un modèle commun). Nous devons être un pont entre le monde des ordinateurs et le monde humain (qui est par nature anarchique et imparfait).

Plus que faire preuve de passion, nous devons faire preuve de compassion (« souffrir avec l’autre »).

L’humilité doit remplacer l’ego; l’inclusion doit remplacer l’élitisme, la coopération doit remplacer la compétition, l’apprentissage doit remplacer la position du sachant, l’attitude de mentor doit remplacer l’attitude « rock star ».

2 belles références bibliographiques à retenir de cette belle session :

Jour 1 – Keynote de clôture : « The gordian knot → Hatching Software Development Ecosystems »

Dans cette keynote, Alberto Brandolini part du postulat que tout est connecté à tout (le noeud gordien du titre), et que nos choix de développeurs ont des conséquences fortes sur les interactions sociales, et sur la culture de nos sociétés qui en découle.

Pour trouver un sens à nos métiers, il faut aligner nos objectifs long et court terme. Il faut également retrouver les 3 facteurs de motivations humains : autonomie, maitrîse et finalité.

Gros focus également sur la notion de feedback : pour qu’un système s’améliore, des feedbacks réguliers sont nécessaires. Il faut aussi que les acteurs du système soient encore dans le système pour bénéficier des améliorations pour les motiver à soumettre des pistes. En cela, l’approche DevOps (« you build it you run it ») et la stabilité des équipes peuvent aider.

LA référence bibliographique de cette keynote : Accelerate.

Synthèse sur ce jour 1

Je suis ressorti de ce premier jour avec beaucoup de questionnements, et des tonnes de livres à lire pour approfondir. Donc ce fut une belle journée !

0 commentaires

Soumettre un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Découvrez nos autres articles

Aller au contenu principal