Andrew Harmel-Law - Power Structures and their Impact on Software

[00:00:06] Alors, je vais commencer la présentation maintenant. Alors, je vais commencer la présentation maintenant, pour ne pas déborder.
[00:00:13] Donc, ce dont je vais parler aujourd'hui, ce sont les structures de pouvoir, plus précisément les structures de pouvoir sociétales, et leur impact sur les logiciels. Cette partie n'est pas la présentation. C'est la partie où je vais vous expliquer la présentation, car il est important que vous compreniez certaines choses. Alors, euh, je m'appelle Andrew Harmer Law. Je suis architecte technique chez ThoughtWorks. Mes pronoms sont "iel", et ce n'est pas écrit sur la diapositive, mais je suis aussi autiste et probablement TDAH. Cette partie est importante. Donc c'est comme ça, cette conférence compte beaucoup pour moi. C'est super important. Alors j'aimerais avoir des discussions à ce sujet. J'aimerais aussi avoir une séance de questions-réponses à la fin. Mais cela signifie aussi que je pourrais me laisser emporter et partir sur des quêtes secondaires, ce qui est tout à fait une chose autistique. Ce qui est cool, mais si vous essayez de faire en sorte que la conférence dure le bon temps, alors ça peut être mauvais. Il y a donc une quête secondaire dans cette conférence, qui est intentionnelle, et elle a des diapositives. Donc si je fais cette quête secondaire, c'est bien. Si je fais d'autres quêtes secondaires, vous pouvez me regarder fixement et je serai ramené à la réalité, et je me souviendrai que je suis censé rester sur la bonne voie. Euh, mais le truc, c'est comment savoir si je suis sur une quête secondaire ou si je fais la vraie présentation ? Vous ne savez pas. Donc ce que vous devez savoir, c'est cette chose ici.
[00:01:33] Alors, quelle est la structure de la conférence ? Voici la structure de la conférence. Première partie, encore une fois, à cause de l'autisme, j'ai appris un tas de choses, j'ai lu beaucoup de choses, et je suis très enthousiasmé par elles, et je vais vous le dire, que vous l'aimiez ou non. Beaucoup d'entre elles sont déprimantes. Donc c'est un avertissement. Parce que ce sont des faits et je vais vous dire, vous aimerez, à moins que vous ne puissiez partir, tout le monde est libre de partir. Mais attention, les faits vont être déprimants. Ils commencent plutôt amusants, puis ils deviennent plus déprimants.
[00:02:02] C'est la partie la plus importante de la conférence parce que l'autisme, très excité.
[00:02:09] Ensuite, à cause de l'autisme, je réaliserai que j'ai partagé trop de faits déprimants et que tout le monde a l'air un peu triste. Alors maintenant, je vais utiliser ma capacité à reconnaître des schémas et à voir des schémas, encore une fois, Dieu bénisse l'autisme.
[00:02:24] Je vais essayer de comprendre et d'expliquer à tout le monde pourquoi nous sommes si déprimés, n'est-ce pas ? Je vais donc vous donner un cadre de réflexion sur les raisons pour lesquelles ces mauvaises choses se produisent. Mais ça ne vous fera pas vous sentir mieux, vous comprendrez simplement mieux pourquoi vous êtes déprimé. Alors c'est la troisième partie. Enfin, je vais vous parler de choses cool que vous pouvez regarder et rechercher.
[00:02:47] Euh, pour faire en sorte que les mauvaises choses cessent de se produire. Et puis la quatrième partie, qui est minuscule à la fin.
[00:02:55] Et c'est secrètement une publicité pour mon livre, parce que j'ai écrit un livre, que j'oublie toujours de mentionner, j'ai écrit un livre. Quatrième partie, parce que tout cela est une question de liberté, ou si vous le faites bien, c'est une question de liberté.
[00:03:07] Je ne vous dirai pas quoi faire, mais je vous dirai, je vous donnerai la possibilité d'explorer votre propre futur afin que vous puissiez être libre et faire des choses. Et la raison de tout cela est d'écrire du code dont vous êtes fier et avec lequel tout le monde aime travailler, car cela est lié au code.
[00:03:24] Voilà pour le préambule. Maintenant, nous pouvons commencer la conférence. Donc, comme je l'ai dit il y a une minute, je vais parler des structures de pouvoir et de leur impact sur les logiciels. La raison pour laquelle c'est important est que le logiciel est un sport d'équipe. Très peu d'entre nous écrivent des logiciels seuls et écrivent le projet entier, n'est-ce pas ? Peut-être avez-vous un projet annexe ou c'est ainsi que vous avez commencé, seul. Mais presque tous, je suis sûr que nous sommes tous payés pour écrire des logiciels avec d'autres personnes.
[00:03:55] Et en raison des choses que nous avons apprises au cours de l'écriture de logiciels, nous acceptons tous maintenant que les influences externes ont un impact sur notre code. Donc, nous savons pertinemment que la structure des équipes et les schémas de communication entre les équipes ont un impact sur notre code, nous l'appelons la Loi de Conway et nous nous référons à ce genre de choses. Et nous savons, même si une grande partie est anecdotique, je l'ai beaucoup vu, n'est-ce pas ? Cela s'applique certainement. Nous savons que c'est suffisamment vrai pour que nous riions tous à la blague quand ils l'entendent, il y a une blague de Michael Nygaard, qui est le département des RH. Le service des ressources humaines réalise le premier jet de votre architecture parce qu'ils décident où vont les équipes et c'est ce qui définit l'architecture. Et nous achetons tous des topologies d'équipe, n'est-ce pas ? Et nous donnons à Manuel Pace et à Matthew Skelton une partie de notre argent.
[00:04:46] Mais je vais argumenter que ce sont aussi des structures de pouvoir social. N'est-ce pas ? Parce que nous ne vivons pas seulement dans ce monde où il n'y a que du travail. Nous vivons dans un monde plus vaste où beaucoup de choses se passent, dont je ne vais pas parler. Mais nous savons tous que beaucoup de choses se passent. Cela se répercute sur le lieu de travail et sur le code que nous écrivons. C'est donc ce que cette présentation va aborder.
[00:05:08] Mais cette conférence, comme je l'ai dit, ne va pas vous prendre pour acquis. Ce que je vais faire, c'est essayer de décrire et de vous donner une idée de ce qui se passe, puis d'essayer d'expliquer pourquoi, ou pourquoi je pense que cela se produit, et enfin d'essayer de vous donner des raisons de vous en sortir.
[00:05:22] Donc première partie, faits déprimants. Ce fait n'est pas déprimant. C'est une conférence très cool que Vlad Kononov a donnée à DDD Europe en Check, je sais que c'est 2022. Euh, et ça s'appelle la géométrie fractale de la conception logicielle, parce que Vlad réfléchit très fort et il trouve des titres cools. C'est une conférence super, super intéressante, et je continuerai à y faire référence. Parce qu'en fait, Vlad parle des dynamiques, de l'énergie de l'architecture logicielle et de la conception logicielle, et il dit ce que nous devrions faire pour avoir une bonne conception. Ce que je vais faire, c'est en discuter et en quelque sorte dire pourquoi je pense que cela est influencé par les structures de pouvoir sociétales. Ce que Vlad dit, c'est que fondamentalement, l'énergie de la conception logicielle et de l'architecture logicielle tourne autour de l'organisation des connaissances. Alors, et vous pouvez le voir dans le code, c'est la partie facile, n'est-ce pas, qui, espérons-le, n'est pas controversée. Il dit qu'il y a différents niveaux d'organisation de la connaissance du code, n'est-ce pas ? En gros, nous prenons la connaissance et nous l'encapsulons. Il existe différents niveaux d'encapsulation, donc les niveaux d'encapsulation pourraient être, j'ai une liste que je viens de découvrir, car c'était une conférence sur la conception de domaine. Le plus haut niveau était le contexte délimité, parce que les gens du DDD adorent le contexte délimité, le niveau suivant était les services, le niveau suivant était les composants, le niveau suivant était les modules. À l'intérieur des modules, il y a des classes, donc il y a tous ces éléments fractals imbriqués, n'est-ce pas, que nous utilisons pour organiser les connaissances. Donc ce qu'ils font, c'est qu'ils mettent en quelque sorte un voile autour de la connaissance, comme s'ils délimitaient la connaissance. Et puis vous en avez plusieurs.
[00:07:08] C'est donc un logiciel, n'est-ce pas ? Mais le point clé est, et c'est ce que Vlad a souligné, ce que je trouve super important, ce n'est pas seulement à nous de déterminer où va la connaissance. Parce qu'une partie de cette connaissance est partagée. Et le point de Vlad, que je trouve super puissant. C'est que la gestion de cette connaissance partagée, la conscience de celle-ci et la façon dont nous en tirons parti sont essentielles. Et l'autre point important de Vlad est que plus nous partageons la connaissance, plus notre code est couplé. Donc il dit qu'il y a quatre niveaux. Le premier niveau est le pire et ça s'améliore. Alors, quatre niveaux de couplage des connaissances. Premièrement, le couplage d'implémentation, c'est le même code, coupé-collé à deux endroits différents. C'est donc en fait différent, mais c'est littéralement la même chose, donc si vous devez apporter une modification, vous devez modifier deux morceaux à deux endroits du code, c'est mauvais. Le niveau suivant est le couplage fonctionnel, donc ça fait la même chose mais différemment. Mais vous changez la même chose.
[00:08:11] Ensuite, le couplage de modèle, puis le couplage de contrat, donc le couplage de contrat est le moins, n'est-ce pas ? Nous partageons donc un contrat, mais nous ne partageons pas notre représentation interne. Donc ce n'est pas nouveau, n'est-ce pas ? C'est ce que nous apprenons lorsque nous étudions l'architecture et la conception logicielles. Mais l'idée de Vlad est que tout tourne autour de la connaissance et de sa gestion. Par conséquent, si vous avez beaucoup de données qui transitent entre deux composants ou deux contextes délimités ou autre, et qui sont couplés par contrat, ils sont toujours moins couplés qu'un minuscule morceau de données qui transite entre deux systèmes couplés par implémentation. Parce que le couplage ne réside pas dans la quantité de données qui circulent entre les différents composants, le couplage réside dans la connaissance qui se trouve à chaque extrémité. Alors. Cela signifie que la structure du code est la gestion des connaissances.
[00:09:02] Et si nous avons une bonne architecture, ce que j'appellerais une bonne architecture signifie que nous avons une base de code plus hospitalière et un endroit plus agréable pour être, vivre et travailler, c'est une architecture qui gère cette connaissance et donc une qui gère ce couplage. Ainsi, la structure du code est la gestion des connaissances. La structure du code est la gestion des connaissances.
[00:09:23] Et c'est le premier fait qui, je pense, n'est pas controversé.
[00:09:27] Personne ne fronce trop les sourcils pour l'instant, donc tout va bien. Premier fait, le code est une connaissance, n'est-ce pas ? Donc nous prenons les choses que nous savons sur le monde et nous les transformons en code. Et la façon dont nous partageons cette connaissance affecte la conception du système, n'est-ce pas ? C'est donc la loi de Conway et tout ça, n'est-ce pas ? Donc si les choses sont plus couplées, cela affecte la conception et l'indépendance des équipes. Le degré de partage dicte donc le degré de couplage. Mais il y a d'autres faits.
[00:09:57] Alors, l'inspiration pour le fait numéro deux vient de ce livre d'Adam Thornhill, qui est votre code en tant que scène de crime.
[00:10:05] C'est un excellent livre. Quand j'ai fait cette conférence la première fois, Adam était dans le public et j'ai admis que je n'avais pas lu le livre, ce qui est dommage. Donc je n'ai toujours pas lu le livre, mais j'ai travaillé avec beaucoup de gens qui me parlent constamment du livre. Et le point de ce livre d'Adam est que le code se souvient. Et donc, évidemment, le code se souvient dans le dépôt, dans nos, vous savez, dépôts de contrôle de version, vous pouvez revenir en arrière avec Git et voir l'historique du code source. Mais plus important encore, et c'est pourquoi votre code est une scène de crime, vous pouvez voir les traces de choses qui se sont passées il y a six mois, un an, cinq ans, comme si. Je travaille actuellement sur une base de code pour un client, qui est euh, ou plutôt, je travaille près, pas dedans, près d'une base de code qui a 20 ans. Des décisions prises il y a 20 ans hantent encore les personnes qui gèrent la base de code aujourd'hui.
[00:10:55] Et c'est là le point, n'est-ce pas ? Parfois ces choses, elles ne se contentent pas d'enregistrer ce qui est connu maintenant, c'est un enregistrement de ce qui était connu dans le passé et comment cette connaissance a été gérée et comprise. Donc, fait numéro deux, le code est un enregistrement de la connaissance, n'est-ce pas ?
[00:11:15] Et c'est un enregistrement de la façon dont nous avons collectivement compris un problème. Parce que nous ne travaillons probablement pas seuls, nous travaillons en groupe, donc c'est la connaissance collective, n'est-ce pas ? Et comment nous utilisons le code pour gérer et maintenir cette connaissance.
[00:11:33] Et, comme je l'ai dit, parce que c'est en quelque sorte toujours dans la base de code maintenant, les décisions que nous avons prises dans le passé auront abouti à du code qui affectera les décisions que nous prenons maintenant, n'est-ce pas ? Donc si vous voulez un bon exemple, je suis sûr que vous pouvez peut-être penser à des exemples. Les meilleurs exemples sont certaines des décisions de conception qui ont été prises par les très intelligents concepteurs et développeurs des bibliothèques Java, ils ont pris quelques décisions, des décisions de conception qui les hantent ou comme les concepteurs des bibliothèques d'utilitaires de date Java, n'est-ce pas ? Il y a un tas de choses dans les dates, qu'ils n'ont probablement pas cru être un problème, et maintenant tout le monde les déteste parce que tout le monde déteste la date, et puis ils ont introduit le calendrier, que tout le monde déteste, et tout ça. Ainsi, des choses qui semblent très petites sur la façon dont vous maintenez les connaissances peuvent entraîner de grandes différences.
[00:12:18] Donc ça fait partie, fait un et fait deux.
[00:12:22] Fait numéro un, le code est une connaissance, fait numéro deux, le code est un enregistrement de la connaissance. Mais il y a autre chose, qui est important, et je pense que c'est de plus en plus important maintenant. Alors que les nuages et tout le reste arrivent et que les ordinateurs deviennent plus puissants. Euh, nous pouvons faire beaucoup de choses avec les logiciels, n'est-ce pas ? Il y a tellement de choses que nous pouvons faire avec les logiciels, nous nous sommes un peu effrayés en construisant des LLM et en les utilisant, et nous ne sommes pas vraiment sûrs de ce qu'ils font, et nous pensons que c'est cool, mais nous sommes aussi un peu terrifiés, n'est-ce pas ? Donc les logiciels sont assez puissants. Il brûle aussi des tonnes de combustibles fossiles et détruit lentement l'écosystème, mais nous faisons comme si cela n'existait pas parce que c'est plutôt cool de pouvoir lui demander d'écrire du code pour nous et qu'il le fasse. Donc les ordinateurs sont puissants. Ce pouvoir appartient aux personnes qui ont la capacité de modifier le code et d'appliquer cette modification en production, n'est-ce pas ? Les personnes qui ont le pouvoir de le déployer. Et ce pouvoir peut être utilisé pour de bonnes raisons, pour de mauvaises raisons, intentionnellement, involontairement, n'est-ce pas ? Il y a juste qu'il a du pouvoir, quelle que soit la façon dont cela se produit.
[00:13:30] Et donc ce pouvoir revient finalement au code. Donc le code est super puissant.
[00:13:35] Et il transmet ce pouvoir aux personnes qui peuvent manipuler ce code. Alors, petite quête secondaire, c'est ce qui m'inquiète le plus avec les LLM que n'importe quoi d'autre. C'est comme si beaucoup d'entre nous disaient, un LLM peut écrire le code, c'est bien, et puis personne n'est vraiment en contrôle, c'est comme si un LLM en avait le contrôle. Donc le code est le pouvoir. Et donc il transmet ce pouvoir à ceux qui peuvent le manipuler.
[00:14:01] Le meilleur exemple de ceci est un article de blog. Et c'est si petit que vous ne pouvez pas le lire intentionnellement, parce que je ne veux pas que vous le lisiez, je vais résumer cet article de blog maintenant. Il y a un article de blog intitulé "L'Ascension du Maître de Donjon" par Alberto Brandolini. Il est célèbre pour de nombreuses raisons, y compris le storming d'événements. Je pense qu'il devrait être célèbre pour avoir trouvé de bons titres d'articles de blog et de bons noms pour les choses, car il est doué pour cela. Mais en gros, il décrit cette chose appelée le Maître du Donjon. Le Maître du Donjon, ou vous pourriez les considérer comme un gardien de jeu, Maître du Donjon pour moi est quelque chose de cool parce que j'ai grandi dans les années 1980 en jouant à des jeux de rôle. Et puis d'une manière ou d'une autre, j'ai fini par travailler dans l'informatique, ce dont je n'ai aucune idée de comment c'est arrivé. Mais autisme plus jeu de rôle égale informatique. Euh, mais oui, il décrit cette chose appelée le Maître du Donjon. Donc le Maître du Donjon est quelqu'un qui est comme un maître, et j'utilise le mot maître à dessein, probablement pas une maîtresse, parce que c'est probablement une personne blanche d'âge moyen, n'est-ce pas ? Un homme. Ils sont les maîtres de la base de code, n'est-ce pas ? Ils sont les maîtres de la base de code parce qu'ils l'ont écrite ou qu'ils en ont écrit la plus grande partie. Et puis tous les autres sont partis en hurlant. Ils ont donc construit cette base de code de donjon, ils savent où sont tous les pièges, ils savent où sont toutes les erreurs, ils savent où sont toutes les mauvaises décisions architecturales, toutes les choses dont ils ne sont pas fiers. C'est la personne, n'est-ce pas ?
[00:15:17] Cela signifie que si quelqu'un veut apporter des modifications à la base de code appartenant au Maître du Donjon, vous devez vous adresser au Maître du Donjon, sinon vous tomberez dans un piège et vous serez blessé. Le Maître du Donjon est donc le gardien de toutes ces modifications. Ça veut dire qu'ils ont beaucoup de pouvoir, n'est-ce pas ? Ils peuvent dire oui ou non à des choses s'ils n'aiment pas quelqu'un. Ils peuvent dire non, même si c'est une très bonne chose et même si le PDG dit que c'est une bonne idée, nous devrions absolument le faire, si le Maître du Donjon veut dire non, le Maître du Donjon peut dire non. Donc il y a beaucoup de pouvoir, ils sont partout. Partout où je vais, il y a un Maître du Donjon. Peut-être êtes-vous un Maître du Donjon, si c'est le cas, ne vous inquiétez pas, je ne suis pas impoli envers vous. Parce que les Maîtres de Donjon, comme si vous lisez toutes les vieilles histoires fantastiques, n'est-ce pas, et que vous jouez à tous ces jeux, il y a toujours une histoire, ils n'ont pas choisi de devenir le Seigneur de ce donjon horrible ou piégés par cette base de code, les choses se sont juste passées et ils se sont retrouvés là, ils ne le font pas exprès généralement. Je n'ai pas encore rencontré de Maître du Donjon maléfique dans la vraie vie. Le meilleur exemple dans le projet Phoenix est Brent. Alors quand vous rencontrez Brent, vous vous dites, oh, Brent va être un idiot, Brent va être un méchant, Brent est en fait la personne héroïque. Il dit : "Je ne veux pas vivre dans ce donjon où je suis la personne qui doit être présente à chaque modification de code et je connais tous les scripts shell bizarres que j'ai écrits pour que tout reste en vie." Brent est le Maître du Donjon, mais Brent essaie de réparer le donjon, de le nettoyer, n'est-ce pas, de le transformer en un joli quartier gentrifié. C'est donc ça le but, les Maîtres du Donjon n'y arrivent pas. D'après mon expérience, intentionnellement. Alors rassemblons quelques faits. Le code est savoir et pouvoir, et ce sont en quelque sorte les deux faces d'une même pièce, n'est-ce pas ? Alors il y a euh, une expression en anglais, il y a probablement une version en français, connaissant l'anglais, nous l'avons probablement volée aux Français et l'avons ensuite transformée en anglais. Mais l'expression est le savoir est un pouvoir, il y a probablement une version française de cela à venir.
[00:17:13] Euh, donc ce sont les deux faces d'une même pièce, n'est-ce pas ? Elles sont l'intérieur et l'extérieur de la même chose.
[00:17:20] Mais la force, pardon, le troisième fait qui se situe un peu au milieu, c'est l'histoire. Ce qui se passe, c'est que parce que le code se souvient, il se souvient de ce genre de dynamique de pouvoir et il l'incorpore et en quelque sorte l'ossifie et le transforme en pierre, n'est-ce pas, ce qui le rend difficile à changer parce que le code est difficile à changer, n'est-ce pas ? Nous aimerions que ce soit facile à changer, Vlad serait très heureux si vous achetiez son livre et découvriez comment rendre votre code facile à changer, mais la raison pour laquelle le livre de Vlad existe est que nous ne le faisons pas, et donc Vlad s'est senti obligé d'écrire ce livre.
[00:17:52] Mais ce ne sont pas seulement les structures de pouvoir des équipes et des personnes, mon argument est que et je vais continuer à partager d'autres faits. Mon argument est que cela ne se produit pas seulement à cause de structures de pouvoir organisationnelles, comme qui est le manager et quelle équipe est où.
[00:18:06] Je pense que ce sont aussi des structures de pouvoir sociétales.
[00:18:09] Il ne s'agit pas seulement de savoir qui a travaillé sur quel code et quand. Je pense que c'est plus puissant que ça. Alors.
[00:18:16] J'ai perdu ma souris, c'est bien.
[00:18:19] Parce que je pense que le code est la connaissance et le pouvoir sociétal.
[00:18:24] Alors, maintenant, au lieu d'être quelqu'un qui se contente de monter sur scène et de vous dire des choses parce que je les pense, je vais vous donner plus de faits parce que j'ai lu beaucoup de choses sur Internet. Alors, numéro un. Ce euh, document est incroyable, vous devriez absolument le lire, il est gratuit sur internet. Il s'intitule "Différences de genre et biais dans l'acceptation des demandes de tirage (pull request) en open source par les femmes par rapport aux hommes". Il ne mâche pas ses mots. Vous devriez absolument le lire, c'est vraiment surprenant. En fait, ce n'est pas surprenant du tout, mais c'est vraiment surprenant.
[00:18:54] Euh, c'est de 2016. Ce qu'ils ont fait, c'est qu'ils ont examiné toutes les requêtes de tirage (pull requests) de tous les projets open source sur GitHub, donc leur ensemble de données est volumineux. Numéro un, comme l'ensemble de données doit être petit, non, l'ensemble de données est grand.
[00:19:08] Alors ça commence de manière très intéressante, ils vous accrochent dès l'abstrait. Comme il est dit, étonnamment, nos résultats montrent que les contributions des femmes ont tendance à être acceptées plus souvent que celles des hommes. Et vous vous dites, ça va être une lecture intéressante. incroyable, vous devriez absolument le lire. C'est gratuit sur internet. Il s'appelle 'Différences de genre et biais dans l'acceptation des requêtes de fusion open source des femmes versus des hommes'. Il ne mâche pas ses mots. Vous devriez absolument le lire. C'est vraiment surprenant. Eh bien, en fait, ce n'est pas surprenant du tout, mais c'est vraiment surprenant. Euh, c'est de 2016, ce qu'ils ont fait, c'est qu'ils ont essentiellement examiné toutes les requêtes de fusion sur tous les projets open source sur GitHub. Donc leur ensemble de données est grand. Numéro un, comme les données doivent être petites, sachez que l'ensemble de données est grand. Donc, ça commence de manière très intéressante, ils vous accrochent dès le résumé. Comme il est dit, étonnamment, nos résultats montrent que les contributions des femmes ont tendance à être acceptées plus souvent que celles des hommes. Et vous vous dites, ça va être une lecture intéressante.
[00:19:22] Malheureusement, cependant, les taux d'acceptation des femmes sont plus élevés seulement quand personne ne sait qu'elles sont des femmes, n'est-ce pas ? Donc, les femmes écrivent les meilleures requêtes de fusion de code, mais dès que quelqu'un sait qu'elles sont une femme, ces requêtes de fusion sont moins acceptées. Elles sont donc plus acceptées quand personne ne sait qui vous êtes, dès que les gens se disent, oh, c'est définitivement une dame.
[00:19:42] Ooh. D'accord. Ça semble mauvais. Si on ne se soucie que du code, alors ça semble mauvais.
[00:19:52] Par conséquent, comme ils le concluent, bien que les femmes sur GitHub puissent être globalement plus compétentes, un biais à leur encontre existe néanmoins. Alors pourquoi ? Que pourrait-il bien se passer ?
[00:20:02] Dans ce monde logiciel entièrement méritocratique et égalitaire, n'est-ce pas ? Où nous vivons tous ?
[00:20:09] Parce que nous continuons à subir des préjugés, n'est-ce pas ? Donc malgré le fait que ces contributions soient meilleures, car si nous ne connaissons pas le genre de la personne, alors cela est fusionné, n'est-ce pas ? Ils sont moins acceptés, n'est-ce pas ? C'est aussi parce que c'est open source. Et c'est ce qui m'a intéressé. On pourrait soutenir, et je pense qu'un argument solide pourrait être avancé, que si c'était au sein d'une organisation, si ce n'était pas de l'open source, alors ce serait peut-être un effet secondaire de
[00:20:33] le fait que la structure organisationnelle est intervenue et que diverses personnes ont été promues en raison, vous savez, du fonctionnement de la société et des organisations. Il n'y a pas de hiérarchie organisationnelle à protéger dans un projet open source. Vous devriez juste vouloir les meilleures contributions à votre base de code, n'est-ce pas ?
[00:20:53] Par conséquent, c'est fondamentalement du sexisme, n'est-ce pas ? Ce qui est nul, mais c'est vrai.
[00:21:01] Et donc c'est mon mon prochain point, n'est-ce pas, le code est une connaissance et un pouvoir solidifiés, mais c'est un pouvoir sociétal solidifié, n'est-ce pas ? Et parce que, comme nous avons nos faits, le code est un enregistrement écrit de ce qui s'est passé. Encore et encore et encore, n'est-ce pas ? C'est un registre écrit de ce qui s'est passé, mais ce n'est pas un registre écrit, tout comme dans le registre historique de ce qui ne s'est pas passé. Ce n'est pas un enregistrement des requêtes de fusion qui n'ont pas été acceptées. La base de code à laquelle vous soumettez votre requête de fusion de code aujourd'hui, est un enregistrement des est est au-dessus des requêtes de fusion qui ont été acceptées, n'est-ce pas ? Donc le code se souvient de ces choses. Le code est en quelque sorte en train de s'ossifier, comme de se transformer en pierre ou en os, n'est-ce pas, ce qui le rend vraiment difficile. Et c'est le contexte actuel dans lequel les futures requêtes de fusion sont faites, n'est-ce pas ? Donc ce n'est pas seulement le passé, le passé rattrape en quelque sorte le présent. Et puis c'est le monde, le présent dans lequel nous vivons, dans lequel les choses futures se produisent, n'est-ce pas ? C'est donc le paysage où nous nous trouvons en ce moment.
[00:21:59] C'est donc triste, maintenant nous sommes clairement un peu déprimés.
[00:22:03] Parce que, même si vous êtes juste un peu triste que de bonnes contributions de code soient gaspillées à cause d'une chose stupide dans la société, même ça, c'est mauvais, n'est-ce pas ? Il y a beaucoup d'autres choses mauvaises. Mais le simple fait que de bonnes contributions disparaissent, c'est mauvais. Mais peut-être, peut-être, en repensant à Vlad. Peut-être que cela n'arrive que sur les bases de code où c'est plus structuré, n'est-ce pas ? Car s'il y a plus de structure, on pourrait penser que le pouvoir réside peut-être dans une base de code, plus structurée. Ce pouvoir est encore plus difficile à changer, n'est-ce pas, peut-être ? Donc tout ce que nous pouvons faire, c'est,
[00:22:38] Ceci est une image d'un trou dans le sol, mais ça ne ressemble pas à un trou dans le sol. C'est très difficile de trouver une image d'un trou dans le sol qui ait l'air bien. Mais si la base de code est comme une histoire de la couche de tous ces changements les uns après les autres. Où devrions-nous aller pour jeter un œil à l'exact opposé ? L'endroit où nous pourrions aller pour voir l'exact opposé est le papier 'Big Ball of Mud', n'est-ce pas ? Parce que le document 'Big Ball of Mud' est la description classique de l'exact opposé, comme si vous voulez faire pleurer Vlad, vous lui agitez probablement le document 'Big Ball of Mud' sous le nez et lui dites : 'C'est la réalité de là où nous vivons'. Donc, regardez le document 'Big Ball of Mud'. Ce que j'ai oublié, parce que j'ai relu le document 'Big Ball of Mud', j'ai oublié qu'il est structuré comme un motif. Ce n'est pas un anti-modèle, c'est avant que nous commencions à décrire les anti-modèles d'une manière différente. C'est décrit comme un modèle. Alors, si nous voulons construire une grosse boule de boue, n'est-ce pas ?
[00:23:32] Nous commençons par un problème. C'est pourquoi les grosses boules de boue existent beaucoup, parce que ce problème est le problème de tout le monde. Nous voulons livrer des logiciels de qualité à temps et en respectant le budget. Tout le monde, c'est une citation directe du document.
[00:23:46] Personne ne retourne à son travail et dit que ce n'est pas ce que nous voulons. Donc, nous faisons tous face à ce problème. Et donc ce que nous faisons, c'est, nous nous concentrons un moment sur les fonctionnalités, nous ignorons Vlad, nous nous contentons de livrer les fonctionnalités. Et nous disons que nous nous concentrerons sur l'architecture et les performances plus tard.
[00:24:04] N'est-ce pas ? Parce que c'est évidemment ce qui se passe. Malheureusement, plus tard ne vient jamais.
[00:24:11] C'est cool, n'est-ce pas, ils décrivent le monde dans lequel nous vivons tous. Ils se concentrent également, et c'est ce qui est intéressant pour moi et pour cette présentation, sur un ensemble de forces qui conduisent à la grosse boule de boue, car celles-ci seules ne suffiront pas à créer une grosse boule de boue. Pourquoi la « Big Ball of Mud » se produit-elle ? Premièrement, il s'avère que certaines personnes sont douées pour travailler dans de grosses boules de boue. Ce qui est un fait. Juste bien. Comme Brent dans le projet Phoenix est doué pour ça car il peut évidemment écrire d'incroyables scripts shell bash et se souvenir de tonnes de choses et est assez efficace à 3h du matin quand il essaie de réparer un P1, n'est-ce pas ? C'est juste Brent.
[00:24:48] Numéro deux, visibilité de la structure. Si je demande à quelqu'un de me construire une maison, et je sais que l'architecture du monde réel est une mauvaise métaphore pour le logiciel. Mais si je demande à quelqu'un de me construire une maison et que vous commencez à construire, si Tron commence à me construire une maison et qu'elle a toutes les pièces que j'ai demandées et qu'elle a l'électricité et l'eau courante, mais qu'elle semble s'effondrer la semaine prochaine, je serai contrarié parce que je peux le voir.
[00:25:13] On ne peut pas voir ça dans le code, n'est-ce pas ? Même si les gens se disent que c'est vraiment mauvais, les chefs de produit et tous les, vous savez, le PDG peuvent dire : 'Je sais, mais c'est bon, on va livrer, on le fera plus tard, on va juste livrer'. Les seules personnes qui peuvent le voir, les architectes en ont un peu le nez, n'est-ce pas, si vous travaillez en tant qu'architecte, ce que je fais. Mais ceux qui savent vraiment sont les gens qui sont là, à subir toutes les coupures de papier chaque jour, n'est-ce pas ?
[00:25:38] Numéro trois.
[00:25:41] J'ai changé le mot complexité parce qu'il déclenche certaines personnes car ce n'est pas techniquement de la complexité. C'est la complexité d'apporter des changements. En d'autres termes, c'est incroyablement difficile de modifier le code, n'est-ce pas ?
[00:25:52] Et c'est comme ça que ça dérive lentement si vous commencez avec quelque chose de vraiment agréable qui rend Vlad heureux, n'est-ce pas ? C'est donc comme un couplage partagé via nos interfaces et contrats. Si vous voulez avancer vite, concevoir un contrat entre deux équipes est beaucoup plus lent que de simplement faire un copier-coller du code de leur base de code et de le mettre dans ma base de code et nous le corrigerons plus tard. Donc tout remonte dans cette liste de choses et rend Vlad très malheureux. Mais ça le fait aller plus vite. Ainsi le système s'érode. Par conséquent, c'est difficile, vous avez donc besoin de quelqu'un qui est plus habile à travailler dans la 'big ball of mud'. Donc le volant négatif se met en marche.
[00:26:27] La prochaine citation ennuyeuse et déprimante : de nombreux ingénieurs considèrent travailler avec une 'Big Ball of Mud' comme normal. C'est comme si je n'étais jamais allé nulle part et que j'avais la chance d'être consultant. Partout, partout il y a une grosse boule de boue quelque part. Peut-être que c'est tout leur système, peut-être la moitié de leur système. Tout le monde suppose simplement que c'est naturellement là où ça doit être.
[00:26:50] Et certains ingénieurs sont particulièrement doués pour naviguer dans ces bourbiers. C'est donc ça qui étend la métaphore.
[00:26:58] Et par conséquent, les gens qui se soucient vraiment des choses, les compétences de quelqu'un qui dit : 'Nous devrions concevoir cela correctement, nous devrions faire du refactoring, nous devrions mettre à jour l'architecture'. Ils peuvent le demander encore et encore, mais la chose qu'ils demandent devient de plus en plus grande. Mais les forces sont de le faire fonctionner, de livrer la fonctionnalité. On reviendra la semaine prochaine et on arrangera le truc, l'architecture, non ? Alors les guides des marécages deviennent plus précieux parce qu'ils peuvent juste expédier, n'est-ce pas ? Brent est devenu Brent dans le projet Phoenix parce que Brent pouvait livrer. Même si Brent, vous savez, savait que c'était probablement une mauvaise chose, mais il est plus important que l'entreprise gagne de l'argent, n'est-ce pas ? Donc le guide du marais devient lentement un gardien, n'est-ce pas ?
[00:27:38] Donc le code est une connaissance et un pouvoir structurés.
[00:27:42] Mais c'est un point clé, tout le monde ne devient pas un guide des marais, tout le monde ne devient pas Brent, n'est-ce pas ?
[00:27:48] Il y a une bonne question, pourquoi Brent ou le gardien ou le maître de donjon est-il toujours un homme blanc d'âge moyen ? Et ce n'est pas que les Blancs d'âge moyen, les hommes blancs, sont mauvais, n'est-ce pas ? Personne ne fait ça comme ça. Si ce schéma se répétait sans cesse, ce serait une mauvaise chose, n'est-ce pas, donc quelque chose d'autre doit se passer.
[00:28:11] Et mon argument est, et je vais essayer d'expliquer pourquoi dans une seconde, tout cela se produit encore et encore à cause des structures de pouvoir sociétales, n'est-ce pas ? Il y a des choses qui nous impactent, nous affectent et nous poussent d'une manière telle que cela se produit encore et encore.
[00:28:25] Donc, dernière série de faits déprimants.
[00:28:29] C'est un document qui n'a rien à voir avec le logiciel. Il s'appelle 'La tyrannie de l'absence de structure' et c'est un article sur les expériences du féminisme de la deuxième vague écrit par Joe Freeman. Euh, je pense dans les années 70 ou 80. Mais en gros, Joe travaillait dans des groupes de type structuralistes, des groupes auto-organisés. Mais qui n'avaient explicitement aucune structure. Le but était de, au diable le patriarcat, nous n'aurons aucune structure, nous allons juste nous organiser. Cela a très bien fonctionné pour la prise de conscience, donc quand les gens expliquaient des choses et s'enseignaient mutuellement, c'était incroyable. Le document de Joe, cependant, souligne que dès que ces groupes ont commencé à vouloir faire des choses, comme même faire des tracts, n'est-ce pas, pour changer la société, les choses ont commencé à mal tourner. Alors,
[00:29:21] Et le point de Joe est que l'absence de structure n'existe pas, dès que vous essayez de faire quelque chose comme écrire du code, n'est-ce pas, il y a une structure.
[00:29:30] Alors,
[00:29:32] l'idée d'absence de structure n'empêche pas la formation de structures informelles, n'est-ce pas ? Tout ce que ça arrête, c'est si vous dites, oh, on ne peut pas avoir de structure, ça arrête juste les structures formelles. Donc encore une fois, si Roméo dit, nous devrions absolument avoir une réunion régulière et nous disons, non, c'est une structure, nous ne pouvons pas avoir de réunion régulière. Il pourrait toujours y avoir des réunions fréquentes, mais c'est juste qu'elles sont informelles, n'est-ce pas ?
[00:29:57] L'absence de structure devient alors un écran de fumée pour les forts ou les chanceux afin d'établir une hégémonie incontestée sur les autres. Hégémonie est un mot difficile à prononcer, alors je l'ai pratiqué. Donc ça a l'air maléfique, n'est-ce pas, ça ressemble un peu à ce que je suis tombé d'une falaise sur internet. Et je suis tombé dans un terrier de lapin et je deviens tout paranoïaque. Ça empire.
[00:30:17] Parce que ensuite Joe Freeman utilise le mot élite. Maintenant, élite est un mot surchargé, n'est-ce pas ? De nos jours, les élites.
[00:30:25] Je ne parle pas de ce genre d'élites. Joe dit : les élites sont les gens qui font ça. Mais comment Joe définit-il les élites ?
[00:30:32] Une élite, ennuyeusement, est un petit groupe de personnes qui ont du pouvoir sur un grand groupe dont elles font partie. Donc ça semble un peu suspect et effrayant, n'est-ce pas ?
[00:30:42] Heureusement pour nous, les élites ne sont rien de plus, rien de moins que des groupes d'amis, n'est-ce pas ? Joe n'est donc pas devenu paranoïaque. Ce sont juste des gens qui traînent ensemble, n'est-ce pas ?
[00:30:54] Et ce qui se passe, c'est que ces groupes d'amis, parce qu'ils se ressemblent, n'est-ce pas, fonctionnent comme des réseaux de communication en dehors des canaux réguliers. Donc si on pense à Conway, les schémas de communication dictent notre logiciel, n'est-ce pas ? Alors parfois, si nous disons qu'il n'y a pas de communication, qu'il n'y a pas de structures formelles, ce qui est le cas si vous avez des équipes, les équipes communiquent, c'est évident. Parce que Conway parle de modèles de communication, pas d'équipes, n'est-ce pas ? Mais ça marche parce qu'il y a généralement des équipes formelles. Les choses fonctionnent toujours, les modèles de communication ont toujours un impact sur les choses, le logiciel, car le logiciel se souvient, même s'il n'y a pas de structure formelle.
[00:31:30] Parce qu'il y a une structure, elle est juste informelle.
[00:31:34] Alors,
[00:31:36] les élites sonnent cool, comment puis-je vouloir être une élite ?
[00:31:40] Heureusement pour moi, pour être une élite, vous n'avez pas besoin de. le bon ou désolé, vous avez besoin du bon parcours, peau blanche, homme. La bonne personnalité et la bonne gestion du temps. Je n'ai pas de temps libre. Mais si j'avais beaucoup de temps libre, je serais la bonne personne pour cela. Heureusement aussi pour moi, l'appartenance à l'élite n'inclut pas l'exigence que je sois compétent, ce qui est bien, car je ne suis pas compétent. Dédié au féminisme. Je suis assez dévoué au féminisme en fait. Mais dans ce cas, le dévouement à la livraison de bon code, c'est bien, je n'ai pas à m'en soucier.
[00:32:12] Je n'ai pas besoin d'être talentueux. Ou je n'ai pas vraiment besoin de potentiellement contribuer. C'est donc bon. Je peux faire des conférences en Europe et toujours être membre d'une élite.
[00:32:27] Et c'est la chose clé, donc le code, et c'est le point que je vais aborder, c'est la dernière partie des choses déprimantes, puis nous passerons au légèrement moins déprimant.
[00:32:34] Le code est une connaissance et un pouvoir structurés et il structure les choses que nous le voulions ou non, n'est-ce pas ? Il intègre, il se souvient des choses, les choses que les structures de pouvoir sociétales, comme nous l'avons vu dans le document GitHub, autorisent en quelque sorte et il ne se souvient pas des choses que nous n'avons pas la chance de nous souvenir, n'est-ce pas ?
[00:32:54] Il inscrit cela dans le code et il se souvient très longtemps.
[00:33:00] Il capture tous les regroupements et tous les biais que nous avons non pas parce que nous sommes mauvais ou bons ou parce que les gens choisissent de faire des choses, c'est juste que tout ce qui se passe inconsciemment dans la société se produit simplement parce que le code est super bon pour se souvenir de ces choses, n'est-ce pas ? C'est incroyable comme il y parvient. Donc toutes les fragilités humaines avec lesquelles nous vivons tous, n'est-ce pas, et beaucoup d'entre nous essaient de les réparer. Mais si vous ne faites rien, ça finira par s'infiltrer dans la base de code de toute façon, n'est-ce pas ?
[00:33:29] Vous n'avez pas besoin d'être mauvais, donc pour être très clair, je n'ai pas dit cela la dernière fois que j'ai fait cette présentation. Et je pense que ça a contrarié certaines personnes, vous n'avez pas besoin d'être un méchant pour que cela arrive. Vous n'êtes pas un méchant, et c'est probablement, ce sera un homme, vous n'êtes pas un méchant si vous êtes une élite, vous êtes juste
[00:33:41] vous êtes, par accident de naissance, prédisposé à être dans cette chose, n'est-ce pas, où vous avez plus de temps libre et etc.
[00:33:50] Mais cela arrive au code, n'est-ce pas ? Alors.
[00:33:56] C'est l'œil de Sauron, pour ceux qui l'ont déjà oublié. Alors,
[00:34:03] si cela se produit, n'est-ce pas, et je dirais, donc cela se produit et cela prédispose les choses à être de grosses boules de boue, ce qui rend Vlad triste. Donc si le seul objectif que vous avez de cette présentation est de rendre Vlad Konlov heureux. C'est un être humain charmant, il mérite d'être rendu heureux. Il achète, mais vous pouvez acheter mon livre. J'ai des exemplaires gratuits. Euh, mais achetez aussi le livre de Vlad. Mais comment rendre Vlad heureux, car le point de Vlad est de faire si nous avons une gestion structurée des connaissances, alors c'est une meilleure base de code pour travailler, n'est-ce pas ? C'est moins couplé, le couplage est littéralement le fléau de la vie de chacun. Si nous avons une charge cognitive plus gérable, c'est plus facile, les changements sont plus faciles, c'est juste plus amusant de faire notre travail. C'est ça l'argument, n'est-ce pas, pas parce que nous devrions tous faire tout le reste.
[00:34:46] Alors.
[00:34:50] Si nous sommes dans ce système, comment le réparer ?
[00:34:54] Que pourrions-nous faire pour le changer ? Pouvons-nous travailler avec cette idée de la connaissance en tant que code, en tant que connaissance et pouvoir ? Comment pouvons-nous faire en sorte que cela fonctionne pour tout le monde, c'est-à-dire que cela continue de fonctionner pour moi, mais aussi pour tout le monde, n'est-ce pas ? Pour ce faire, nous devons savoir comment les déséquilibres sont corrects. C'est un livre à la mode à citer, vous devriez absolument le lire. Il y a un tas de critiques. Je ne suis ni anthropologue ni archéologue, donc je ne sais pas si c'est correct ou non. La raison pour laquelle je mentionne ce livre, qui est le 'Dawn of Everything' de David Wengrow et David Graeber,
[00:35:29] c'est que dans le livre ils soutiennent qu'il existe différentes manières de s'organiser, n'est-ce pas ?
[00:35:34] Il existe différentes manières de s'organiser qui n'ont pas à être la façon dont nous, en Occident, organisons actuellement nos sociétés. C'est juste que partout où nous regardons, c'est comme ça que la société est organisée. Mais ils ont des tonnes et des tonnes d'exemples de différentes façons dont différentes sociétés se sont organisées pendant des milliers d'années. Ils parlent même de certaines sociétés qui s'organisent différemment selon la période de l'année, elles changent donc leur mode d'organisation en fonction de l'environnement. Ce qui est cool. Alors.
[00:36:01] Pourquoi est-ce important ? Citation d'Ursula K. Le Guin : Nous vivons sous le capitalisme, son pouvoir semble inéluctable, tout comme le droit divin des rois. On a l'impression, vous savez, parfois on a l'impression que c'est comme ça que ça marche parce que ça marche, n'est-ce pas ? Ça ne fonctionne pas équitablement pour tout le monde, ça fonctionne mieux pour certaines personnes que pour d'autres. Mais si nous obtenons une, vous savez, une base de code, si nous la limitons aux bases de code où il est plus facile pour tout le monde de contribuer, alors je peux bénéficier de toute l'intelligence astucieuse de tous mes collègues. Et nous pouvons avoir de bonnes choses. Donc, comme Ursula nous le rappelle, le pouvoir humain peut être résisté. Donc c'est juste que nous l'avons inventé. Nous pouvons inventer de nouvelles choses. Alors, qu'est-ce que nous inventons ?
[00:36:40] Il y a trois prérequis pour que le pouvoir soit inégalement distribué, ce qui est la manière dont ces choses se produisent. Regardons-les. Le premier, c'est la quête annexe que j'ai le droit de faire. Est-ce celui-ci ? Écrire du code, c'est cool. Soyons super honnêtes. Il y a très peu de carrières où, si vous arrêtiez de nous payer, nous écririons probablement encore du code. N'est-ce pas ? Nous ne l'écririons pas pour l'entreprise qui ne nous paie pas, mais nous ferions probablement encore quelque chose, nous écririons du code parce que l'écriture de code est cool, n'est-ce pas ? C'est incroyable. Malheureusement, nous avons très rarement l'occasion d'écrire du code seuls, n'est-ce pas ? Donc ce que nous devons faire, c'est écrire du code avec d'autres personnes. Donc, quand nous écrivons du code avec d'autres personnes, certaines des libertés que nous avons quand nous sommes seuls doivent être abandonnées parce que je ne veux pas contrarier ou gêner tous les autres qui font leur travail. Donc nous devons renoncer à certaines de ces libertés, n'est-ce pas, ce n'est pas mauvais, c'est juste comme ça que ça marche quand la société s'organise. Alors, j'ai plein de ces petites choses. Nous devons renoncer à une partie de ce pouvoir, le pouvoir ultime que nous avons en tant qu'individus pour travailler en équipe.
[00:37:47] Alors. J'en ai trop. Alors. Des choses importantes se produisent lorsque la suppression de la liberté a lieu. Et c'est ce à quoi vous devez prêter attention. Et cela rejoint en quelque sorte certains des points que Steven soulevait, cela rejoint certains des points que Thierre soulevait hier. Vous devez prêter attention à certaines choses, n'est-ce pas ? Parce que supprimer une liberté est important. Qui décide quelles libertés sont supprimées ? Vous entendrez donc Steven, plus tôt dans la conversation, juste avant moi, parler du fait qu'il ne va pas dire aux équipes ceci, il va demander aux équipes si elles devraient faire quelque chose. Terry parlait encore d'équipes autonomes et autogérées, n'est-ce pas ? Alors qui décide ?
[00:38:25] Qui l'impose ? D'accord, si vous dites, nous avons besoin, je pense que c'est une mauvaise idée, mais si vous dites que deux personnes doivent commenter une pull request et que seulement une personne le fait, vous savez, ou que personne ne commente votre pull request et que vous forcez la fusion. Quelqu'un doit dire que ce n'est pas cool, n'est-ce pas, alors qui le fait ?
[00:38:42] Et qui le met à jour, n'est-ce pas ? Donc parfois les règles changent. Encore une fois, Steven parlait du fait que lorsqu'ils ont commencé petit, vous ne voulez pas, lorsque c'est un petit groupe, vous avez quelques libertés qui sont supprimées. Parce que vous n'avez pas besoin de beaucoup de bureaucratie. Parce que je peux crier par-dessus le comme le le le cube à la personne à côté de moi et ils le répareront. Mais si c'est plus grand, alors peut-être avons-nous besoin d'un bot Slack. Si c'est plus grand, à un moment donné, nous aurons probablement besoin de Jira, n'est-ce pas ?
[00:39:08] C'est là que nous devenons super français. Donc si vous avez aimé, vous pouvez faire attention, si vous ne savez pas qui c'est, vous pouvez lire la partie en bas. Parce que j'ai fait ça pour parler dans un autre pays et j'ai réalisé que personne ne devrait être censé connaître l'histoire de France. Alors, numéro un. La liberté de prêter attention au numéro un, c'est comme qui restreint les libertés.
[00:39:27] Et dans le livre, ce n'est pas le contrôle de la punition, mais je ne veux pas être trop dur dans cette discussion, alors je l'ai changé en contrôle de la punition. Si vous voulez lire le livre, il y a un mot plus fort que punition dont ils parlent. Le point clé est que vous devez prêter attention à qui contrôle la punition, n'est-ce pas ? Si c'est un fabuleux roi blanc, alors les choses pourraient mal tourner, vous voyez où cela va. mais nous aurons probablement besoin de Jira. N'est-ce pas?
[00:39:07] Donc, c'est là que nous devenons super français. Alors si vous avez, vous pouvez faire attention. Si vous ne savez pas qui c'est, vous pouvez lire la partie en bas. Parce que j'ai fait ça en parlant dans un autre pays et j'ai réalisé que personne ne devrait s'attendre à connaître l'histoire de France. Donc, premièrement, la liberté de faire attention au numéro un, c'est comme qui restreint les libertés? Et dans le livre, ce n'est pas le contrôle de la punition, mais je ne veux pas trop insister là-dessus dans cette conférence, alors je l'ai changé en contrôle de la punition. Si vous voulez lire le livre, il y a un mot plus fort que punition dont ils parlent. Mais l'essentiel est que vous devez faire attention à qui contrôle la punition, n'est-ce pas? Si c'est un roi blanc fabuleux, alors les choses pourraient mal tourner. Vous voyez où je veux en venir.
[00:39:48] Le point clé est que dans le monde du logiciel, il y a des punitions formelles, comme qui est embauché, qui est viré, qui obtient une augmentation, etc. C'est tout, vous savez, et nous savons tous cela, n'est-ce pas? Des choses peuvent arriver. Cinq minutes. Oh, je pourrais dépasser un peu. Euh, mais dans le code aussi, les choses informelles, comme qui est sollicité pour faire les revues de code, n'est-ce pas? Le code de qui, vous savez, est plus fiable, etc., etc. Les choses informelles dans le code, je pense qu'elles sont aussi, sinon plus, importantes, ou plutôt plus restrictives en raison du pouvoir du code, n'est-ce pas?
[00:40:24] Rappel clé numéro un.
[00:40:27] Encore une fois, pas besoin de deviner ce que c'est, c'est le serment du Jeu de paume. Mais, vous ne pouvez pas tout enlever, si vous enlevez tout contrôle, ce sera le chaos. Donc, vous devez avoir une forme, nous le savons tous, la plupart d'entre nous le savent probablement. Ça n'a pas bien marché, mais ça a bien commencé, n'est-ce pas? Donc ce que vous voulez faire, c'est le maintenir en marche, d'accord? Vous devez abandonner certaines libertés. Vous ne pouvez pas simplement abandonner toutes les libertés parce que vous essayez de collaborer en tant que groupe, une petite société qui essaie de livrer du code, n'est-ce pas? Et de maintenir du code.
[00:40:55] Ce à quoi vous devez faire attention, c'est quand certaines personnes clés ont tout le pouvoir de faire ces trois choses clés, n'est-ce pas? Comme décider qui décide, appliquer les choses et changer les choses.
[00:41:08] Cependant, certaines personnes s'en fichent, n'est-ce pas? Ils agissent comme, ok, je sais que je pourrais être viré si ça arrive, mais je vais le faire quand même, n'est-ce pas? Donc il doit y avoir une autre source de pouvoir, que ces gens-là possèdent, qui n'est pas liée au fait qu'ils soient au sommet et qu'ils puissent dicter ce qui va se passer, n'est-ce pas? Pourquoi agissent-ils sans peur? C'est donc la deuxième chose que Graber et Wengro soulignent. Et cela a du sens si l'on y pense, travailler avec du code nous donne du pouvoir, n'est-ce pas? Brent devient important dans le projet Phoenix, mais ils sont en quelque sorte tirés des niveaux inférieurs à cause de la personne qui détient tout ce pouvoir. Alors, quel est le pouvoir qu'ils ont? Ils ont le contrôle de l'information, ou ils comprennent le code. N'est-ce pas? Comprendre le code est super puissant, n'est-ce pas?
[00:41:56] Par conséquent, nous avons accès à ce pouvoir. Si le code n'est pas bien géré, n'est-ce pas, si cela ne rend pas Vlad heureux, et que certaines personnes connaissent tout de certaines parties de la base de code et personne d'autre, c'est mal, n'est-ce pas? Nous savons tous que c'est mauvais, mais c'est la raison pour laquelle c'est mauvais.
[00:42:11] Ce sont les gens qui deviennent les gros bonnets de la boue, ce sont les gens qui sont naturellement prédisposés à être l'élite, ce sont les gens qui peuvent travailler léger, n'est-ce pas? Je pourrais être très bon pour travailler dans des bases de code de type grosse boule de boue, mais si je dois rentrer à la maison pour mes enfants, alors je ne peux pas. Quelqu'un d'autre pourrait être aussi bon que moi, mais il n'a pas d'enfants et il peut travailler jusqu'à minuit. Ils sont simplement naturellement prédisposés, juste à cause de la vie.
[00:42:34] Donc mon point est que ce code suralimente cela. Celui-ci, vous n'en êtes peut-être pas conscient. Il s'agit d'Edmund Burke, un Anglais qui essaie d'effrayer les Anglais à propos de ce qui se passe en France parce qu'en Angleterre, ils ont utilisé les terribles événements de Paris comme raisons pour une répression supplémentaire au Royaume-Uni parce que nous nous disons, eh bien, nous ne voulons pas que cela arrive parce que regardez ce qui se passe en France. Donc, le code le suralimente de la même manière, n'est-ce pas? Comme vous pouvez en quelque sorte avoir ce pouvoir supplémentaire. Alors,
[00:43:03] C'est si puissant, nous le faisons accidentellement tout le temps. Je peux écrire du code avant le déjeuner que je ne comprends pas après le déjeuner. Donc le code a ce pouvoir, n'est-ce pas, juste en donnant un mauvais nom à quelque chose, cela ne fonctionne pas. Ou vous pensez au code, comme je peux écrire du code, et puis laisser un client sept ans plus tard, ce mauvais code peut encore avoir du pouvoir sur les gens parce que je n'ai pas mis les bonnes choses. Deux minutes. Je vais aller vite. Alors, étant donné cela, pourquoi ne voyons-nous pas des déséquilibres de pouvoir partout? Eh bien, pour ce faire, nous devons nous souvenir des choses. Vous avez besoin de contrôle de la punition et de contrôle de l'information. Mais il y a le troisième facteur. Quel est le troisième facteur? Ce que Wengro et Graber soulignent, c'est que vous n'avez pas besoin de toutes ces trois choses. Je vous dirai quelle est la troisième chose dans une minute. Vous n'avez besoin que de deux des trois. Donc, généralement, vous voyez quelqu'un de haut rang qui connaît tous les détails du code, n'est-ce pas? Mais que se passe-t-il si vous avez quelqu'un qui connaît juste le code et qui n'est pas de haut rang? Qu'est-ce qu'ils ont?
[00:44:00] Charisme individuel. Alors devinez qui nous allons voir pour ça? C'est Napoléon Bonaparte. Alors, une petite, vraiment petite personne de Corse, arrive soudainement et certains diront qu'à cause d'un très grand charisme, tout le monde a suivi ce que Napoléon faisait. Et vous pouvez voir cela dans le code, n'est-ce pas? Comme parfois ce code, et j'ai une autre image ici, il s'agit d'une collection de rants de Linus.
[00:44:28] Il y a des parties de la base de code qui sont difficiles à changer parce qu'elles sont difficiles à changer dans la base de code de tout le monde. Il y a des parties de la base de code, que j'ai vues maintes et maintes fois, qui sont difficiles à changer parce que vous avez peur de contrarier la personne qui a écrit le code. N'est-ce pas? Et ce n'est probablement pas une personne de haute hiérarchie. Je sais que dans ce cas, Linus est au sommet de l'arbre. Mais vous le voyez aussi, comme les gens sont juste terrifiés à cause du charisme qu'ils ont.
[00:44:54] Et ils sont tous les deux très difficiles à déloger. Et à cause du code, le pouvoir peut disparaître, cela continue. Le pouvoir peut disparaître s'il n'est pas gardé quelque part. Pouvoir informationnel, n'est-ce pas? Soudain, si vous ne savez pas, mais le problème avec le code est que le code est très bon pour être difficile à, il est très difficile de déloger les gens qui se font aspirer dans cette chose. Et encore une fois, personne ne le fait exprès. Les gens sont juste aspirés dedans parce qu'ils ont plus de temps libre.
[00:45:21] Donc, les distributions inégales de pouvoir sont un problème.
[00:45:25] Alors, que faisons-nous pour arranger ça? Donc, pour le réparer, nous devons être conscients des forces en jeu, et pour être conscients des forces en jeu, vous devez écouter ce qui se passe, n'est-ce pas?
[00:45:38] Et vous tomberez dans le même piège. Si vous êtes haut placé dans la hiérarchie et que vous dites, j'écoute, il est très facile de penser que vous écoutez tout le monde, mais ce n'est pas le cas parce que vous êtes haut placé dans la hiérarchie et qu'il y a un tas de gens qui ne sont pas dans les mêmes réunions que vous, qui disent des choses, mais vous n'êtes pas au courant de ce qu'ils disent. Donc pour faire ça, vous devez faire un tas de choses. Vous n'avez pas besoin d'impliquer tout le monde, car cela suppose que même s'ils sont impliqués, ils voudront participer.
[00:46:03] Donc vous devez faire attention à l'apparition de groupes informels, ce qui n'est pas mauvais, n'est-ce pas? Un groupe de personnes qui va jouer au football, pardon, jouer au football un vendredi n'est pas mauvais. Mais vous vous dites, ok, ces gens-là sont-ils aussi en train de devenir les personnes de l'équipe qui réparent toujours les choses, n'est-ce pas? Donc nous devons nous assurer que cela n'arrive pas. Nous devons surveiller les gens qui accumulent les informations. Je cherche des gens qui accumulent les informations.
[00:46:25] Plus précisément, il y a trois libertés auxquelles nous pouvons faire attention.
[00:46:28] Donc premièrement, nous devons protéger la liberté de réorganiser. Donc la liberté de réorganiser dans le logiciel est importante, n'est-ce pas? Donc cela contre le contrôle de la punition. Si nous pouvons réorganiser, si je peux refactoriser une base de code, n'est-ce pas? Alors c'est une bonne chose. Cela signifie que je suis libre d'ajouter, de supprimer ou de modifier les limites, n'est-ce pas? Si je pense que mon équipe devrait posséder plus de choses, je devrais pouvoir parler à l'équipe dont je pense devoir prendre quelque chose, et ensuite nous pourrons nous auto-organiser entre nous, n'est-ce pas? Je ne devrais pas avoir à aller voir la direction pour dire, est-ce que cela devrait nous revenir, n'est-ce pas? Cela devrait nous permettre de passer de la conception une des topologies d'équipe à la conception deux des topologies d'équipe dans notre organisation.
[00:47:07] Mais le besoin devrait venir du collectif, n'est-ce pas? Tout le monde devrait être libre de se réorganiser. Pas dans le chaos, n'est-ce pas? Encore une fois, souvenez-vous que nous devons renoncer à certaines libertés, mais il devrait y avoir un mécanisme pour dire, je pense que les limites ou le code doivent être refactorisés et cela devrait venir de n'importe où. Numéro un. Numéro deux, la liberté de circuler.
[00:47:24] La liberté de mouvement contrebalance le contrôle de la liberté d'information. Ce n'est donc pas seulement la liberté de partir, c'est la liberté de se déplacer vers différentes parties de la base de code, de se déplacer vers différentes équipes. Ou la liberté de déplacer quelqu'un d'une partie de la base de code, n'est-ce pas? Personne ne devrait être coincé sur une partie de la base de code et dire, vous ne pouvez pas me déplacer, je suis la seule personne qui est au courant. Donc toutes ces choses, nous les connaissons en quelque sorte, mais c'est une très belle façon d'y penser, n'est-ce pas? Donc personne ne devrait être inamovible.
[00:47:53] Et puis trois, la liberté de désobéir. Donc encore une fois, avec la mise en garde que cela ne signifie pas que vous pouvez être un imbécile. Mais vous devriez être capable de le faire si, par exemple, c'est quelque chose que nous ferons tous généralement. Mais si vous avez une base de code bien architecturée, comme Vlad en parle, la raison pour laquelle vous avez le moins de partage d'informations possible est que si je veux faire quelque chose dans mon équipe qui est différent d'une autre équipe, mais que mes changements n'auront aucun impact parce que nous avons une belle encapsulation, n'est-ce pas? Et nous n'allons pas provoquer de changement sur aucune autre équipe, alors je devrais pouvoir le faire, n'est-ce pas? Je devrais pouvoir désobéir et changer localement, instituer une manière de travailler différente tant que nous gardons l'objectif global, que nous visons tous, à l'esprit pour avancer ensemble. Alors, rends Vlad heureux. C'est ce que les sous-titres de cette conférence pourraient être. Alors, renoncez aux libertés nécessaires pour collaborer parce que ne soyez pas un abruti, tout le monde déteste les abrutis. Mais abandonnez les libertés, mais assurez-vous d'abandonner les bonnes libertés. Et ces libertés sont la liberté de se réorganiser, la liberté de bouger et la liberté de désobéir. Car le fait est que si nous, et c'est la conclusion, si nous y prêtons tous attention et que nous prenons soin collectivement de ces libertés, ce que nous faisons, c'est nous inoculer contre la lente dérive progressive vers les grosses boules de boue. C'est le point, n'est-ce pas? Je ne dis pas que vous devriez tous être comme des féministes de pointe et tout ce genre de choses, n'est-ce pas? Ou des anticapitalistes ou quoi que ce soit. Mais ce que vous voulez faire, c'est être conscient de ces choses afin de pouvoir voir les forces à l'œuvre, afin de pouvoir vous protéger contre la grosse boule de boue et avoir une architecture consciente, n'est-ce pas?
[00:49:30] Parce que si c'est bon pour tout le monde, alors par définition, c'est bon pour vous, n'est-ce pas?
[00:49:37] Et puis, si nous avons des bases de code que nous pouvons réellement contrôler et dans lesquelles nous aimons réellement travailler, alors à Dieu ne plaise que nous puissions aimer nos emplois encore plus. C'est le genre de chose. Alors faites-le pour le bénéfice de la base de code, pour votre bénéfice, cela bénéficiera à tout le monde. Voilà. Alors enfin, dernière partie, choisissez votre propre aventure. J'ai écrit un livre.
[00:49:58] Il fait 520 pages, mais si vous voulez le résumé d'une page, voici ce que vous faites. Tout est basé là-dessus. En gros, une façon de surcharger cela est d'adopter ce qu'on appelle le processus de conseil architectural, et vous pouvez dire, vous dites ceci en gros, n'importe qui peut prendre n'importe quelle décision, et cela signifie n'importe quelle décision. Mais avant de le faire, et c'est une sorte de contrepoids, vous devez demander conseil, pas permission, conseil à toutes les parties affectées. Donc quelqu'un, en gros quelqu'un qui aurait une histoire mise dans son backlog parce que vous avez fait quelque chose.
[00:50:29] Donc si vous allez les affecter, vous leur dites, et aux personnes ayant de l'expertise, et c'est tout. Il y a 519 autres pages de mon livre qui expliquent comment gérer tout ce qui se passe quand les humains se parlent, mais c'est fondamentalement de quoi il s'agit. Alors merci beaucoup. Je pense que nous avons encore le temps pour des questions. <bruit>
[00:50:58] Oh, et il y a des livres. Je pense que tu as des livres. Vous recevez un exemplaire de mon livre si vous posez une question. Question. Oui. Question.
[00:51:07] Très bien, merci. <bruit> Alors mes excuses si vous avez déjà acheté mon livre, mais merci si vous avez déjà acheté mon livre.
[00:51:17] Comment avez-vous eu toutes ces réflexions? Comment cela est-il né dans votre cerveau?
[00:51:22] C'est une bonne question. Je crois que je lis trop de livres.
[00:51:27] Donc, je lis trop de livres, mais comme j'ai de la chance d'être consultant. Je vois énormément de choses, et je pouvais voir les mêmes personnes être frustrées par des choses. Je vois des "big balls of mud" partout. Vous pouviez voir un tas de choses. Les gens étaient frustrés, mais ce qui m'énervait le plus, c'est que les gens acceptaient le fait que c'était ainsi. Et puis j'ai commencé à expérimenter le processus de conseil délibérément anarchiste.
[00:51:56] Parce que je me disais, si c'était facile à résoudre, quelqu'un l'aurait essayé. Alors je l'ai essayé avec quelques clients et ça a marché. Et je me suis dit, wow, c'est comme, c'est il y a différentes façons d'organiser. Pas nécessairement au niveau sociétal, je sais que c'est très différent, n'est-ce pas? Mais ce genre d'organisation en équipes fonctionne incroyablement bien. Si vous faites confiance aux gens et leur donnez le pouvoir d'essayer de faire les choses différemment, c'est incroyable ce qui se passe. Et c'était ça. Alors je me suis dit, d'accord. Alors je me suis dit, oh, alors j'ai écrit un article de blog pour Martin. En fait, j'ai écrit un fil Twitter, maintenant j'écrirais un fil Blue Sky. se plaindre à ce sujet. Puis j'ai écrit un article de blog pour Martin Fowler et ensuite j'ai écrit un livre parce qu'à chaque fois que j'écrivais quelque chose d'un peu plus gros, les gens l'essayaient et me disaient que ça marchait. Donc je ne pense pas que ça marchera pour tout le monde, mais je pense vous devriez essayer car vous serez surpris si vous faites confiance à vos collègues, c'est incroyable ce qui se passe. Alors,
[00:52:53] Voilà. Il reste deux exemplaires.
[00:52:55] Euh, merci pour votre conférence. Merci. Euh, chaque fois que vous donnez un espace de liberté à quelqu'un, ça ne veut pas dire qu'il l'utilisera. Oui, oui, oui. Euh, quelle est la première étape pour les aider, euh, à avoir la place d'occuper cet espace de liberté?
[00:53:15] Alors, 'pièce' est le bon mot.
[00:53:18] Donc vous avez raison. Si vous faites de la place, si je suis, typiquement, je suis la personne, en raison de ma naissance, je suis la personne qui a le pouvoir et je peux le donner. C'est très difficile de prendre le pouvoir si on ne l'a pas, n'est-ce pas? Mais cela fonctionne mieux si quelqu'un comme moi dit, d'accord, je vais me retirer. Donc vous faites de la place pour les gens, mais vous avez tout à fait raison. Ce n'est pas parce que vous faites de la place qu'il est garanti que les gens diront, c'est incroyable, nous allons faire tout cela. Généralement, il y a juste une grande pause, parce que les gens ne croient pas que vous êtes assez stupide pour le faire, parce que qui ferait confiance aux gens. Et ils ne sont pas sûrs car auparavant, vous ou quelqu'un d'autre a fait tout le travail, l'architecture logicielle, l'organisation des équipes, etc. Ils n'ont donc pas l'expérience, ils ont donc peur. Alors ce que je fais ensuite, c'est que j'essaie de modéliser le processus, comme l'éducation, n'est-ce pas? Où vous essayez de modéliser le bon comportement et de le faire de manière transparente et ouverte et d'encourager les gens à prendre le pouvoir. Tout le monde ne le fera pas, tout le monde ne devrait pas, n'est-ce pas? Tout le monde ne veut pas être comme un leader qui fait des choses. Mais s'assurer que l'espace est toujours là, et pour moi, c'est un peu dans le livre, je suis autiste, donc je parle beaucoup, apprendre à se taire est très puissant. Ce pour quoi je ne suis pas doué. Mais comme créer de l'espace et ensuite maintenir cet espace, et comme encourager les gens à y entrer, ou si vous entrez dans l'espace et que vous faites des choses, être conscient que vous occupez de l'espace et ensuite en quelque sorte vous en retirer après, c'est, c'est la clé. Alors il y a, donc pour ne pas parler d'une autre conférence, mais la semaine prochaine à QCon Londres, la première entreprise avec laquelle j'ai essayé cela en 2020, ils font une rétrospective de quatre ans et ils vont parler explicitement de ce que cela a fait. Alors ils pourraient être, je ne sais pas s'ils vont être impolis envers moi. Et ce sera la dernière question. Oui.
[00:55:09] Euh, merci pour la conférence. Vous en avez parlé rapidement, mais concernant les LLM, euh, maintenant nous avons des gens qui peuvent coder et qui ne pouvaient pas avant, euh, comme le vape coding, etcetera. Euh, pour vous, est-ce un gain de liberté pour les gens qui ne peuvent pas coder parce que le code est pouvoir. Oui, oui, oui. Ou est-ce euh, une suppression de liberté parce que les LLM sont détenus par euh, de grandes entreprises technologiques, euh, et le technofascisme, etc. Oui, oui. Euh, qu'en pensez-vous, quelles sont vos réflexions à ce sujet?
[00:55:45] Donc je pense que c'est les deux. Je pense que cela autonomise totalement les choses, et j'ai vu une conférence vraiment cool, je ne me souviens plus de son titre, mais euh, quelque chose à propos du codage local. Donc cela démocratise le codage, ce qui est une bonne chose, n'est-ce pas? Ça ne devrait pas être comme ça, seul un certain type de personne devrait coder, n'est-ce pas? Tout le monde devrait pouvoir coder. Euh, à un degré plus ou moins grand, n'est-ce pas? Certaines personnes en font des carrières entières, d'autres ont juste besoin d'en faire un petit peu. C'est important. Ce qui m'inquiète, c'est, comme vous l'avez dit, il est très facile de générer beaucoup de code, et ce code est du savoir, et cela vient d'un LLM, qui a juste des tonnes d'hypothèses. Ce qui, comme si nous revenons en arrière, n'est-ce pas, donc Tim Gebru, oh, ça ne revient pas. Ah. Oh, peut-être que ça revient. En bas, ils étaient les scientifiques des données de Google qui, comme, si vous êtes une personne blanche hétérosexuelle, les LLM sont parfaits et reflètent votre réalité. Si vous ne l'êtes pas, les LLM ne reflètent pas la réalité. Donc vous pouvez les changer et les réparer, mais vous devez être conscient. Ce qui m'inquiète, c'est que tout le monde suppose que c'est la réalité, et ce n'est pas le cas, c'est un point de vue très spécifique. Ce n'est pas un point de vue invalide, mais il existe de nombreux autres points de vue. Cela m'inquiète que les gens supposent simplement que c'est le seul point de vue valide, et puis oui, le pouvoir va à cet endroit, et être conscient de cela est super important. Mais je veux dire, c'est facile, n'est-ce pas? Nous savons que la moitié de la forêt amazonienne brûle chaque fois que nous exécutons une requête pour un LLM, mais nous ne le voyons pas, donc c'est en quelque sorte acceptable. Une minute, on a fini. Oh, on n'a pas fini. Dernière question. Nous avons terminé. Ok, cool. Désolé tout le monde. Je dois partir, n'est-ce pas? Merci beaucoup. Merci beaucoup.

Transcription (Traduit)