Rétrospectives et capitalisation

Lundi, en visite chez People In Action, un des partenaires de l'Institut, j'ai eu l'occasion d'une conversation très enrichissante avec Ludovic Perot sur les rétrospectives d'itération. Les équipes de PIA utilisent des pratiques Agiles en interne depuis plus de deux ans, et disposent par conséquent d'un stock important de notes prises à l'occasion de ces rétrospectives. Avec un tel stock il est naturel de finir par se poser la question: que peut-on en faire?

Les informations collectées pendant une rétrospective constituent des données de terrain, des données empiriques dont l'exploitation peut produire de la connaissance. Encore faut-il savoir comment... et pourquoi.

Quand on parle de "connaissance" dans ce domaine, l'une des questions importantes est de savoir quels enseignements généralisables on peut tirer de notre propre expérience.

Une ou plusieurs rétrospectives peuvent nous apprendre des choses comme: "quelle que soit l'heure que nous fixons pour la réunion quotidienne Bob a toujours 10 minutes de retard", ou bien "les repas de fin d'itération ne sont pas très motivants parce qu'on ne trouve pas de resto sympa dans le quartier". Ces informations peuvent être utiles localement - elles peuvent susciter des décisions appropriées - mais on aura du mal à les généraliser: à en tirer quelque chose d'utile pour d'autres projets ou pour d'autres entreprises.

Un enseignement qui se généralise bien pourra souvent s'exprimer sous la forme d'une règle, d'un mécanisme, ou d'un principe: "à chaque fois que A on observe B", ou "dans un contexte caractérisé par X, la pratique Y est plus bénéfique que la pratique Z".

On pourrait établir une hiérarchie des moyens utilisés pour traiter des données empiriques de terrain, selon l'opportunité qu'elles offrent d'en tirer des conclusions généralisables:

• une unique rétrospective d'itération ne permet que de formuler des hypothèses - elle concerne des éléments très ponctuels, qu'il est difficile de généraliser même s'ils sont localement utiles
• l'accumulation de plusieurs rétrospectives d'itération, voire une rétrospective de projet, permet de tirer des conclusions plus claires sur le fonctionnement d'une équipe en particulier: on peut espérer qu'elles se généralisent à de futurs projets confiés à cette même équipe
• la comparaison entre les expériences de plusieurs équipes au sein d'une même entreprise (souvent formalisée par un retour d'expérience) permet de dégager des conclusions plus robustes: si plusieurs équipes ont des expériences convergentes (par exemple "le binômage est une pratique efficace") on peut penser que ces observations s'expliquent par des raisons qui ne dépendent pas de l'équipe (mais peuvent dépendre de facteurs locaux, comme le management ou la culture de l'entreprise)
• la comparaison entre les expériences de nombreuses équipes dans des entreprises ou des contextes différents, par exemple dans le cadre d'une étude statistique, permet de tirer des conclusions plus générales encore.

(Il existe d'autres moyens de tirer des conclusions généralisables de l'étude de données empiriques, tels que l'expérimentation contrôlée, mais je ne cherche pas à faire une liste exhaustive...)

Pour l'instant il reste encore difficile de mener des études au-delà de l'échelle d'une seule entreprise (l'étude PPO de l'Institut étant une des rares initiatives dans ce domaine sur le sujet des pratiques Agiles), mais je trouve intéressante l'idée d'agréger les résultats de nombreuses rétrospectives.

D'une part le retour d'expérience est une forme très intéressante, et à juste titre mise en avant dans de nombreuses conférences: il permet à ceux qui y assistent de juger par eux-mêmes dans quelle mesure les résultats présentés peuvent être liés à des facteurs locaux ou sont potentiellement généralisables à leur propre contexte. De nombreuses pratiques Agiles se sont diffusées précisément de cette façon: parce que ceux qui les avaient expérimentées lors d'un ou plusieurs projets en on fait état lors d'une conférence, propageant l'idée à des personnes dans l'assistance qui, à leur tour, quelques mois ou années plus tard étaient venus présenter des résultats positifs à une prochaine édition.

Mais le retour d'expérience "véridique" est parfois difficile à distinguer d'un discours plus commercial. Sous couvert de dire "voici ce que nous avons fait et pourquoi, et comment ça s'est passé" j'ai trop souvent assisté à des sessions qui ressemblaient à une brochure publicitaire.

L'utilisation de rapports authentiques collectés lors des rétrospectives d'itération et de projet me semble être un très bon moyen de vérifier la sincérité d'un retour d'expérience.

En l'occurrence, chez PIA la démarche adoptée a été de comptabiliser les sujets qui revenaient le plus fréquemment lors des rétrospectives d'itération afin d'établir un "hit parade" des pratiques Agiles les plus discutées. Il en sortira au minimum un billet sur le blog de PIA, mais j'ai aussi insisté auprès de Ludovic pour qu'il envisage de proposer une session à une prochaine conférence.

Cette conversation m'a également donné une idée pour une exploitation un peu plus formelle des rétrospectives d'itération que je vous exposerai dans un prochain billet.

Les développeurs sont-ils des Morlocks?

Il existe une très grande disproportion entre l'importance croissante des métiers du logiciel dans la société, et l'attention qu'on porte à ces métiers dans le discours public.

(Les métiers du logiciel, c'est au sens large toutes les activités spécialisées qui tournent autour de la production de logiciel ou de systèmes à base de logiciel: les développeurs évidemment, puisqu'ils sont directement responsables de la création du "matériau" logiciel, mais également les testeurs, les ergonomes, les "exploitants"... Dans ce qui suit j'utiliserai le mot "programmeur" exclusivement mais c'est à tous ces métiers que je pense.)

Les technologies logicielles sont très récentes, les mots pour les désigner ("software") ne remontent qu'à la fin des années 50 (en France on invente "logiciel" en 70 et il devient officiel dix ans après). Pourtant elles se son répandues jusqu'à l'ubiquité, ou presque. Comptez le nombre d'actes quotidiens que vous effectuez chaque jour qui ne sont possibles que grâce aux créations d'un programmeur: connaissez-vous beaucoup de métiers à ce point indispensables?

Pourtant les programmeurs sont quasi-invisibles: on n'en parle jamais, ou très rarement, me semble-t-il, dans "les média" - journaux, télévision ou radio - destinés au grand public. (Si vous n'êtes pas d'accord, par pitié, citez vos sources!)

On penserait presque aux Morlocks, les êtres souterrains que dévoile H.G. Wells dans La machine à remonter le temps. Le narrateur rencontre d'abord les Eloi, des créatures qui ont la beauté et l'innocence des enfants et vivent à l'abri de tout souci matériel; mais cette situation paradisiaque n'est possible que grâce au travail invisible des Morlocks, indispensables mais dont on nie l'existence en raison du terrible prix de leurs services...

Non, on n'a jamais vu un développeur manger littéralement un utilisateur, mais je crois que nous payons de plus en plus nombreux un lourd tribut à ceux qui crééent les programmes sur lesquels notre quotidien s'appuie: le prix de la non-qualité, des frustrations perpétuelles devant la machine qui vient de "bouffer" un document qu'on a passé des heures à rédiger, des engins qui sont censés "parler" entre eux mais qui ne veulent pas se reconnaître, des téléphones qui "plantent" en milieu de conversation...

Mais aussi (et là on s'approche peut-être plus du destin des Eloi) des appareils médicaux qui irradient des patients, ou des ambulances qui n'arrivent pas à temps. Ces incidents graves font d'ailleurs partie des rares occasions où l'on parle brièvement de ce substrat invisible de la société moderne qu'est le logiciel.

Est-ce, d'ailleurs, à cause de la quasi-totale invisiblité de nos professions que l'éducation des programmeurs est à ce point déficiente? Ou bien est-ce parce que nous n'arrivons pas, justement, à exister en tant que professionnels qu'on ne parle pas de nous? Où est l'effet, et où est la cause?

Lancement de l'étude Projets - Pratiques - Objectifs

Version courte: l'Institut Agile lance aujourd'hui son étude "Projets - Pratiques - Objectifs" (PPO), et si vous utilisez des pratiques Agiles sur vos projets, vous pouvez nous aider. Il suffit pour cela de remplir ce questionnaire préliminaire en ligne, très court, de le faire très largement circuler autour de vous, et d'indiquer si vous êtes volontaire pour participer à l'étude complète.

• Le questionnaire exploratoire sur SurveyGizmo
• Le descriptif de l'étude (en anglais) sur Github
• L'article "When Agile Met Data" 

Cette étude est soutenue par un programme de l'Alliance Agile ainsi que par les partenaires de l'Institut: Microsoft, Neoxia, Exakis, People In Action, Axones, UT7, Agile To You, Yaal, Agilidée.

Version longue:

Depuis plus de dix ans que l'on parle d'Extreme Programming, de Scrum et plus généralement de pratiques Agiles, se fait entendre une question récurrente tant de la part des adeptes que des simples curieux ou des critiques: "où sont les chiffres prouvant que ça fonctionne ?"

Pour illustrer ce que fut pendant longtemps la réponse de la communauté à cette question, voici ce qu'on peut lire entre autres dans la première version, publiée fin 2002, d'un essai de Scott Ambler:

•  les approches Agiles sont toutes nouvelles, il n'y a donc pas eu le temps de collecter des chiffres
• l'exigence en matière de "preuve" est excessive, et sert en fait d'excuse à ne pas s'intéresser au sujet
• l'approche Agile s'intéresse précisément à d'autres aspects que ceux mesurés jusqu'à présent, par exemple la réponse au changement plutôt que le respect du plan initial

Ambler explique par ailleurs que sur certains aspects précis, comme la programmation en binômes ou le développement par les tests, on commence dès cette époque à voir paraître des résultats empiriques. Mais son argument principal reste qu'il n'est pas légitime de demander aux évangélistes de l'approche Agile des preuves quantitatives.

Dix ans après...

J'ai souvent l'occasion de le répéter ces jours ci, la situation a beaucoup changé au cours des dix dernières années. Suffisamment changé pour que les objections ci-dessus n'aient plus cours, à mon sens:

• dans les années 2000-2006, la communauté Agile militait pour obtenir des entreprises où nous travaillions la permission d'utiliser ces approches; aujourd'hui non seulement cette permission est accordée, l'initiative de leur mise en place vient de plus en plus des entreprises elles-mêmes, les projets se réclamant d'une approche "Agile" se multiplient, et par conséquent depuis au moins quelques années la matière existe à établir des résultats quantitatifs;
• il n'est pas exact que ce sont les "réfractaires" qui exigent ces preuves; on s'aperçoit à l'usage que dans les entreprises qui souhaitent sincèrement en généraliser l'utilisation, certaines fonctions, par exemple les acheteurs, utiliseraient ces chiffres s'ils étaient disponibles pour orienter leurs choix;
• la question "quoi mesurer" n'est sans doute pas la plus importante, en tout cas tant que la communauté Agile continue... à ne pas mesurer grand-chose.

La version la plus récente de l'article d'Ambler cite désormais des résultats chiffrés, en dépit de cette posture qu'on aurait pu interpréter comme défensive; en fait, Ambler a initié depuis quelques années un grand nombre d'enquêtes visant à répondre à ces demandes d'éléments quantitatifs.

Là où le bât blesse, c'est qu'il s'agit de questionnaires diffusés via le Web. De tels questionnaires peuvent donner un aperçu fort utile de la popularité de divers éléments du discours agile, mais ils ne sont pas adéquats pour tirer des conclusions généralisables quant à la pratique, sur le terrain, de ces approches et quant aux résultats obtenus.

Il existe par ailleurs un certain nombres d'études académiques sur le mode de l'étude de cas ou de l'expérimentation contrôlée. Il s'agit, respectivement, soit de suivre de près un projet pour mieux mettre en évidence les mécanismes par lesquels une approche Agile apporte (ou non) les bénéfices prétendus; soit de réaliser un protocole expérimental qui permettra d'isoler un facteur particulier en confrontant deux situations entre lesquelles ce facteur est la seule différence. Dans les deux cas, il s'agit de travaux de longue haleine et nécessitant d'importants investissements, en termes de temps et d'argent.

Les données manquantes

Ce qui n'a pas (ou très peu) été réalisé jusque là, c'est une collecte directe des données de terrain qui se généralisent: celles produites par les projets de plus en plus nombreux qui, dans un nombre également croissant d'entreprises d'horizons très divers, mettent en place des pratiques Agiles pour des raisons purement pragmatiques - ce qui veut dire, dans bien des cas, sans se soucier beaucoup de la "pureté" de leur approche, mais en adoptant au cas par cas les pratiques qui leur semblent judicieuses.

Les conférences, telles Agile France (anciennement XP Day France, issue du cycle européen XP Day), donnent à la communauté une excellente occasion de livrer des informations empiriques, sous la forme de retours d'expérience (REx pour les accros des acronymes). Ils ont été et continuent à être une bonne source d'informations qualitatives.

Ils ont cependant un talon d'Achille, la fiabilité des informations produites. En effet, lors de la présentation d'un retour d'expérience il est facile d'attribuer ses succès à des pratiques qui n'y ont pas beaucoup contribué; de passer sous silence certaines erreurs ou épisodes embarrassants, et ce d'autant plus qu'on citera le nom de l'entreprise où l'on travaillait. Par ailleurs un retour d'expérience suppose que le projet soit allé au bout, on va donc éliminer d'emblée les projets qui ont échoué très rapidement; de la même manière on occultera souvent ce qui se passait en début de projet au bénéfice des événements les plus récents.

L'étude PPO

L'objectif de l'étude PPO est de traiter des projets de façon longitudinale, afin d'obtenir des résultats quantitatifs susceptibles d'un traitement statistique. Elle vise à identifier et décrire des projets le plus tôt possible afin d'éviter les biais de sélection, par exemple celui qui ne consisterait à décrire que les projets ayant réussi ou qui se sont terminés à peu près dans les conditions initialement prévues.

Les questions auxquelles l'étude vise à répondre sont les suivantes:

• quelles pratiques sont choisies pour obtenir quels objectifs (délais, qualité, productivité...)?
• quelles pratiques s'avèrent faciles ou difficiles à adopter?
• quelles pratiques effectivement adoptées contribuent réellement aux objectifs fixés?

Afin d'obtenir des réponses fiables, l'étude s'appuiera sur le Référentiel des pratiques, et s'appuiera pour la collecte des données sur des entretiens (idéalement en personne, au besoin par téléphone) avec les intervenants et décideurs des projets concernés, par exemple pour évaluer le degré d'utilisation réelle des pratiques Agiles déclarées.

L'Institut Agile bénéficie d'une position privilégiée pour répondre à ces questions: c'est une entité neutre et indépendante qui peut donner aux entreprises participantes des garanties de confidentialité des données qui lui seront confiées. L'Institut s'emploie à plein temps à ce rôle d'observateur de la mise en place sur le terrain des pratiques Agiles, ce travail ne souffrira donc pas d'interférences comme cela peut être le cas pour une entreprise ayant par ailleurs des activités commerciales qui entâcheraient son objectivité, ou des consultants freelances qui pourraient être accaparés par leur activité.

Si vous êtes intéressés pour participer à cette étude et aider à mieux mettre en lumière les effets réels des pratiques Agiles, n'hésitez pas à vous manifester en remplissant le questionnaire!

Le Principe de Gilb

Aujourd'hui, en préparant une mise à jour majeure du Référentiel, je me suis "reposé" de l'écriture du code d'indexation (en Ruby) en écrivant quelques fiches, dont celle de la pratique "Niko Niko", un import japonais d'autant plus intéressant qu'il m'a donné l'occasion de rappeler le Principe de Gilb

Si vous avez besoin de quantifier quelque chose, il existe toujours une manière de le faire qui soit préférable à ne pas le quantifier du tout.

Le Principe de Gilb est un bon antidote à l'un des travers les plus pernicieux du management des projets de développement logiciel: quand on se pique de gérer ces projets de façon empirique, en se basant sur des éléments objectifs et donc quantifiés, on finit en général par ne mesurer... que ce qui est facile à mesurer, mais rarement ce qui est pertinent.

Par exemple, la motivation, le bien-être d'une équipe ont généralement un effet déterminant sur les résultats qu'elle obtient. Mais comme aucun élément objectif ne permet de rendre ces paramètres immédiatement visibles, ces préoccupations passent souvent au second plan dès qu'on utilise par ailleurs des chiffres rendant compte de la productivité ou de la qualité.

Dans une approche Agile on cherche à mesurer en premier lieu ce qui est pertinent, ce qui est déterminant, même quand c'est difficile à mesurer. Et si on ne sait pas mesurer ce qui a de l'importance, ça n'a pas de sens de dépenser énergie et créativité à mesurer ce qui n'en a pas.

Attention toutefois: le Principe de Gilb ne dit pas que quantifier quelque chose qui ne l'était auparavant pas est systématiquement une bonne chose, et surtout pas que quantifier en vue d'encourager les équipes à atteindre des objectifs chiffrés est une bonne chose. (Lisez en particulier l'excellent Measuring and Managing Performance in Organizations si jamais la tentation vous vient du "management par les objectifs chiffrés".)

Devops - premières rencontres et survol

Ce mercredi 1er décembre j'ai eu le plaisir de participer à la première rencontre Devops parisienne; en voici un compte-rendu, et bien sûr je vais tenter de répondre à la question que vous vous posez déjà: "Devops, qu'est-ce que c'est encore que ce bidule ?"

Commençons par les ingrédients: un petit groupe (une douzaine de personnes) qui se réunissait dans une ambiance informelle et très auto-organisée, la plupart ne connaissant pas les autres participants présents, simplement pour discuter d'un sujet qui leur tenait à coeur: recette classique pour passer une soirée passionnante. (Merci au passage à nos hôtes, Theodo, et aux initiateurs, Philippe, Samuel et Fabrice.)

Ajoutons des bières et des pizzas; en effet "Devops" est un raccourci pour "developers and operations", c'est à dire des intervenants du développement (appelés diversement programmeurs, développeurs, codeurs, "softeux", etc.) et de l'exploitation ("exploitants", ingénieurs de production, administrateurs systèmes, etc.). Vous aurez compris qu'on est entre techniciens...

Pourtant il y a là deux cultures très différentes, et on s'en aperçoit vite à mesure que le tour de table pour faire les présentations commence, chacun y allant de son "troll", petite pique pour deviner à la réaction de chacun qui fait partie de quel bord, ça donne à peu près: "je m'appelle X et je préfère vi à emacs, il faut que j'en dise plus?" Le sujet qui nous réunit c'est justement le rapprochement entre deux cultures que l'organisation usuelle des projets de développement a eu tendance à séparer. (Parfois littéralement, au sens "les développeurs dans la grande salle du 3è étage, les exploitants à la cave".) Certains des effets néfastes de cette séparation sont proverbiaux dans la profession: "excuse n°1 du développeur: ça marche sur ma machine!".

Après le tour de table Raphaël a proposé d'organiser le reste de la réunion en Open Space, ce qui nous a permis d'apprécier l'étendue des sujets qui nous intéressaient. De mémoire et en vrac:

• des outils (Chef ou Puppet) pour gérer les configurations système
• exploiter la virtualisation du développement à l'exploitation
• intégrer la création de packages dans le build automatisé
• déploiement maîtrisé des applications Web 
• ...et d'autres que j'oublie...

 Cette liste ne vous apprend sans doute pas grand-chose sur ce que veut dire "Devops"? C'est justement tout l'intérêt de cette communauté naissante.

Je m'explique: de façon très similaire à l'invention en 2001 du terme "Agile", la communauté Devops est née du sentiment diffus d'un certain nombre de personnes qu'elles avaient, chacune dans leur coin, eu des idées convergentes pour résoudre des difficultés lancinantes dans leur métier. En se rencontrant et en donnant un nom (une étiquette, certes) à cette convergence elles espèrent donner plus de visibilité à la fois à ces difficultés et aux solutions proposées.

Il s'agit donc de briser les "silos" qui isolent les développeurs et les exploitants chacun dans leur coin, avec de nombreuses conséquences néfastes: par exemple des projets qui semblent "réussis" techniquement (code propre et bien testé) et fonctionnent très bien... jusqu'au jour de la "mise en prod" où rien ne va plus: quelques connections simultanées et le serveur "tombe", ou encore une base de données ralenties par des accès mal conçus.

On retrouve dans cette volonté de "déspécialiser" une constante de la culture Agile, au sein de laquelle d'ailleurs les fondateurs de Devops ont fait leurs armes. Le discours Agile a cherché à modifier, voire à effacer les frontières entre développeurs et clients, entre développeurs et testeurs, ou plus récemment entre développeurs et ergonomes; Devops vise à abolir une frontière supplémentaire. Plutôt que développer dans leur coin des applications qu'ils vont ensuite "balancer par-dessus le mur" aux exploitants, les développeurs sont encouragés à travailler dès le début du projet avec eux et à les intégrer à l'équipe.

De même que le discours Agile s'oppose à des approches "cérémoniales" ou totalisantes du développement, de même Devops se positionne comme une réponse "Agile" aux démarches ITIL ou Cobit très prisées dans le domaine de l'exploitation.

On retrouve donc dans l'approche Devops, d'une part des outils et pratiques "empruntés" à l'approche Agile:

• outils de management visuel (on parle de "visible ops") pour créer de la transparence
• alignement sur un rythme itératif et incrémental (mettre en production au rythme du développement)
• automatisation du test
• intégration continue

Mais on va également trouver dans Devops des solutions spécifiques, transposant l'approche Agile au métier de l'exploitation, ou qui visent à établir un nouveau contrat avec les développeurs:

• l'automatisation du "build" ne doit pas se cantonner à produire un exécutable mais va jusqu'au bout de la chaîne en produisant un "package" dont l'installation est répétable et même automatisable
• considérer la description d'une infrastructure système comme du code, et intégrer ce code à la gestion de version au même titre que le code applicatif; c'est l'intérêt d'outils comme Chef ou Puppet
• de même qu'on ne teste pas à la main, on n'installe pas à la main, on ne configure pas à la main, etc. - tout ce qui est manuel et répétitif représente de la connaissance et il faut capturer cette connaissance sous la forme de fichiers texte ou de code
• intégrer très tôt dans le cycle de développement les questions de surveillance et de gestion de l'application, de benchmarking des performances, etc. - en d'autres termes adopter une vision d'ensemble
• plus généralement considérer qu'on est "tous dans le même bateau" et qu'il n'est pas productif de chercher "à qui reviennent les reproches" lors d'un incident en production: abolir les petits jeux qu'on voit fréquemment pour savoir si c'est un bug ou un défaut de surveillance qui est à l'origine d'une panne par exemple; adopter des outils, des processus et surtout une responsabilité partagées

Vous pourrez trouver plus d'information ailleurs sur le Web:

• What is this Devops thing, anyway? de Patrick Debois
• Devops Best Practices (concis et précis)
• What is Devops? de Rodrigo Campo
• What is Devops? de Damon Edwards

Les parallèles avec la communauté Agile sont intéressants, notamment le fait que la question "qu'est-ce que DevOps" ne donne pas pour l'instant lieu à une réponse brève, précise et circonstanciée, le mouvement se dérobant aux tentatives de définition. On pourrait le réduire à des outils: de fait au cours de la soirée de mercredi nous avons beaucoup parlé d'outils (j'ai découvert l'existence de Chef, Puppet, Vagrant et d'autres outils et je vais m'y intéresser, par curiosité et pour ma culture générale), mais ce serait la même erreur que de réduire l'approche Agile à des outils.

Dans les deux cas, il ne s'agit ni de définir des méthodologies, d'imposer des processus ou des outils,  mais de créer, d'animer et de se réclamer d'une communauté; l'objet de cette communauté étant l'élaboration et la conservation d'un ensemble de pratiques, non pas pour leur valeur en soi (on ne "sacralise" pas les pratiques) mais pour les bénéfices que ces pratiques apportent aux projets.

De l'éducation des programmeurs

Dimanche dernier je faisais du ménage... sur mon disque dur: je faisais du tri parmi les nombreux articles sur le génie logiciel amassés depuis des années sur mon disque dur, et je suis tombé sur un essai de David Parnas, "Software Engineering: An Unconsummated Marriage". Une citation m'a accroché l'oeil:

We rarely mention the most basic problem: most programmers are not well educated for the job they do. -- David Parnas

J'ai trouvé la phrase percutante et je l'ai postée sur Twitter. Je vous rappelle que nous sommes un dimanche... Au bout de quelques heures elle avait été "retweetée" par plusieurs dizaines de personnes.

Un "retweet" sur cet outil social réservé aux personnes ayant la durée d'attention d'un moustique (je plaisante...), c'est une façon de dire "bien vu", "je suis d'accord", ou "c'est intéressant". Evidemment c'est une phrase sortie de son contexte - d'ailleurs dans l'article d'origine Parnas argumente pour une profession d'ingénieur logiciel régie par des codes de bonne conduite, des licenses professionnelles obligatoires, et toutes sortes de choses que la communauté Agile réprouve.

Mais quand même, je m'interroge sur cette phrase et le fait qu'elle semble toucher à ce point une corde sensible dans mon "réseau social". Il m'arrive d'avoir d'autres idées que je trouve pertinentes, mais aucune n'a jamais été aussi populaire, en tout cas sur Twitter, que ce simple constat: "Les programmeurs sont très mal éduqués".