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".

MD Day - agilité, modélisation et modélisme

Jeudi dernier, le 25 novembre, se tenait le quatrième MD Day, une journée intéressante à plus d'un titre.

La conférence était hébergée dans le très beau centre de conférences de Microsoft à Issy, auquel le seul reproche que je puisse faire est une connectivité 3G limitée (et je n'avais pas les infos pour me connecter au réseau WiFi en tant qu'invité). Cela n'a pas empêché de nombreux commentaires sur Twitter.

Cette année le thème retenu était "Model-Driven et Agilité", un lien thématique qui se traduisait dans le programme: le mot "agilité" apparaissait dans le titre de quatre des 10 sessions prévues, plus une "table ronde" au sein de laquelle Xavier Warzee et votre serviteur avaient pour mission de représenter le point de vue Agile.

J'étais un peu anxieux à l'idée d'apporter en quelque sorte une "caution" Agile à un événement organisé autour d'une approche du développement, le fameux "model-driven", à laquelle je n'adhère personnellement pas et qui peut sembler aux antipodes du discours Agile: en caricaturant, elle semble marginaliser le rôle du développeur (remplacé par la génération automatique de code) au profit de celui de l'architecte (traçant des diagrammes de modèles dans le but de les convertir en code automatiquement).

Lors d'une intervention aux Valtech Days il y a quelque temps, j'avais ainsi opposé "modélisation" et "modélisme":

En fait de modélisation, on pratique trop souvent ce que j'appellerai le "modélisme": une activité somme toute assez prenante, et qui constitue un excellent passe-temps, mais qui ne produit pas des résultats très constructifs. Ma définition de "modèle" est la suivante: un modèle est une représentation d'une situation réelle, qui sans y être fidèle dans tous les détails est utile pour répondre à des questions concernant cette situation.

On peut illustrer le "modélisme" par ce diagramme par exemple, obtenu à l'aide d'un outil UML qui analyse du code existant. Trente classes différentes sur un seul diagramme ce n'est tout simplement pas lisible, pertinent, ou utile: c'est uniquement une perte de temps.

Il me semblait cependant important d'accepter l'invitation, pour plusieurs raisons. D'une part, je suis favorable aux échanges entre les diverses communautés de professionnels qui se retrouvent autour d'une volonté commune d'améliorer leur pratique d'un métier, en l'occurrence le développement de logiciels. D'autre part, la communauté "model driven" me semble avoir un rapport plus étroit avec le milieu de la recherche, privée ou publique, que la communauté Agile, et l'une des missions de l'Insittut est de resserrer ces liens.

De ce point de vue, l'important était de participer. Mais je me devais d'apporter un regard plus attentif, et dès le début de la journée je m'étais fixé comme objectif de répondre à la question suivante: la communauté "model driven" ici présente est-elle motivée par un réel intéret pour les pratiques agiles, ou s'agit-il (pour l'instant) d'une simple curiosité, piquée par le "buzz" de plus en plus présent autour de l'étiquette "Agile"?

Mon canevas d'évaluation était, comme il se doit, le Manifeste Agile et la liste des pratiques Agiles: lors des sessions, est-ce que les orateurs évoquaient ce qui, dans leurs solutions proposées, privilégiait les individus et les interactions, la livraison de logiciels opérationnels, la collaboration avec le client, et la réponse au changement? Est-ce que les orateurs mettaient en avant l'inclusion dans une stratégie "model-driven" de telle ou telle pratique appartenant à la "boîte à outils" Agile? J'ai prévenu les orateurs des différentes sessions auxquelles j'assistais, afin de ne pas les prendre en traitre, de mon intention de distribuer en fin de journée un "carnet de notes" avec mention des bons et des mauvais élèves.

Alors, quel bilan de cette journée?

Force est de constater qu'il y a encore loin de la coupe au lèvres, et que la communauté "model-driven" n'est pas encore pleinement Agile. Le mot "agile" était plus utilisé pour légitimer un discours déjà établi, que pour y chercher un véritable contenu pouvant constituer un apport.

La première présentation, celle de Grégory Weinbach et Jérémie Grodziski, se distinguait par un rappel explicite du Manifeste Agile, et un véritable "zoom" sur des pratiques, en l'occurrence le Behaviour-Driven Development (BDD) et le Ubiquitous Language issu de l'approche Domain-Driven Design. D'autres éléments Agiles y étaient présents, portant à... quatre le nombre des pratiques Agiles mentionnées lors de cette intervention. C'est honorable mais sans doute en-deça de ce qu'il serait possible de faire en combinant les deux approches, et je suis resté un peu sur ma faim.

Malheureusement, le reste de la journée n'allait pas combler mon appétit pour une mise en valeur de pratiques et de réalités de terrain: les autres sessions auxquelles j'ai assisté se résumaient à peu de choses près à des démos d'outils. La session proposée par l'éditeur W4 abordait (en passant) deux pratiques que j'ai pu reconnaitre comme issues du discours Agile, mais il aurait été plus juste de parler de RAD pour caractériser l'approche présentée. Pour les autres les retours clients étaient (à mon goût) réduits au strict minimum et laissaient la part belle au "pitch" de l'ingénieur commercial montrant (tout seul au clavier) ce qu'on peut faire avec l'outil.

J'ai été particulièrement frappé par une remarque d'un des orateurs, en fin de journée: "pour la suite je vous demande de m'excuser mais il va falloir que je rentre un peu dans les détails du métier de l'assurance...". Mais non, c'est justement l'attention portée au métier de vos clients qui fait, en tout cas pour moi et en tant "qu'Agiliste", toute la valeur et la saveur de votre retour d'expérience.

Car encore une fois, qu'est-ce que modéliser sinon poser des questions à un client dont, en tout cas en début de projet, on ne connaît pas le métier? Pour être vraiment convaincante, une démonstration de l'approche "model driven" soutenue par un outil devrait se tenir sous la forme suivante: on choisit au hasard dans l'assistance une personne qui propose une situation à traiter, issue d'un domaine d'expertise non technique - ou même de la vie courante, par exemple "gérer la fréquentation d'un musée" ou "réserver une table au restaurant" - et on construit en direct une solution à base de modèles. C'est à mon avis dans ce genre d'exercice qu'on s'apercevrait le mieux des bienfaits ou des limites de tel outil ou de telle approche.

Quand on l'aborde sous cet angle, celui où développer des logiciels consiste à encoder et formaliser des connaissances sur un domaine, la distinction entre "code source" et "modèle" commence à mon sens à s'effacer, proposition qui m'a servi de conclusion lors de la table ronde. Toutes les préoccupations que nous avons vis-à-vis du code source sont applicables aux modèles, dès lors que nous sortons du "modélisme" (faire de beaux documents visuels) et que nous cherchons à répondre à la demande d'un client: est-ce que le résultat est correct (ne donne pas des réponses fausses), est-ce qu'il est utilisable (son ergonomie s'adapte à l'utilisateur), est-ce qu'il créée de la valeur?

Dans une approche qui consiste à créer des modèles pour générer automatiquement du code source, cette seconde étape s'apparente à de la compilation, par conséquent le modèle devient le véritable code source. Mais d'un autre côté on constate que les langages modernes (par exemple Ruby) permettent de plus en plus, par le biais de l'abstraction et de techniques comme les DSL, de séparer les préoccupations purement techniques et algorithmiques de l'expression (dans le même langage) des connaissances sur le domaine fonctionnel et des exigences: le code source devient tout à fait adéquat pour exprimer ce qu'on appele en général le "modèle".

Mauvaises conception de la conception

Mon exposé sur les pratiques Agiles liées à la conception a été très bien accueilli à Reykjavik, dont je suis revenu hier très fatigué mais aussi très content.

Mon principal objectif était de faire le lien entre les connaissances accumulées depuis quelques décennies sur les biais cognitifs et l'activité de conception ou "design". J'y ai déjà fait allusion dans mes billets précédents évoquant la danseuse et les bugs du cerveau.

Le point sur la conception

Cet exposé était aussi l'occasion de faire le point sur ce qu'ont été les apports du mouvement Agile au discours sur la conception.

Le terme anglais "design" est très surchargé, que ce soit dans la vie courante (une brosse à dents ou un siège peuvent "être design", c'est une discipline artistique mais aussi industrielle) ou dans le champ professionnel du logiciel, où il peut suggérer aussi bien l'ergonomie (product design, interaction design), l'esthétique (graphic design), la représentation de l'information (information design), ou enfin la conception logicielle à proprement parler.

La terminologie francophone laisse peut-être légèrement moins de place à l'ambiguité, quand on parle de "conception" ce sont le plus souvent les programmeurs qui se sentent concernés.

Avis de décès?

En 2000 paraissait un article important de Martin Fowler, intitulé "Is Design Dead?". A l'époque on ne connaissait que peu Scrum, le "buzz" se concentrait autour d'Extreme Programming et ni l'un ni l'autre de ces discours n'était encore appelé "Agile" - ce n'est qu'à partir de 2001 que le terme issu de la rencontre de Snowbird sera adopté.

On sortait d'une période qui avait vu UML triompher après un long et intense débat sur les notations formelles graphiques, bien illustré dans ce dessin. Pour une grande partie de la profession, "UML" et "conception logicielle" étaient devenus des synonymes.

Fowler relevait l'une des principales critiques à l'égard d'Extreme Programming, auquel on reprochait d'être "centré sur le code". Et de constater le rejet par Extreme Programming non seulement d'UML mais de plusieurs dogmes tout aussi fortement associés à l'idée de conception: le principe d'une "phase de conception" venant en amont de la phase de programmation, celui d'organiser le développement autour de "frameworks" ou de "patrons de conception".

Pour certains, selon Fowler, Extreme Programming semblait vouloir en finir avec la conception. Martin Fowler était en bonne position pour arbitrer ce débat: il était non seulement le co-auteur d'un bréviaire sur UML qui avait connu des ventes record, mais également d'un livre sur le "refactoring" connu comme l'une des pratiques clés d'Extreme Programming, et considéré commel'une des figures tutélaires de cette mouvance.

Non, concluait Fowler, Extreme Programming n'appellait pas à la mort de la conception ni n'annonçait son décès; et Fowler d'attester, en analysant de près les recommandations effectivement émises par Extreme Programming, que la conception y restait une préoccupation majeure, et que ses critiques avaient eu une vision caricaturale de la conception.

Trois mises au point sur la conception

Extreme Programming, et à sa suite le mouvement Agile, ont ainsi permis de rectifier, ou de commencer à rectifier, un certain nombre d'idées fausses sur la conception, et trois exemples me paraissent particulièrement importants.

La conception n'implique pas nécessairement une notation formelle qui s'exprime visuellement. Cette idée a longtemps été le cheval de bataille des tenants d'UML, et le triomphe d'UML au tournant de l'an 2000 était partiellement le triomphe de cette idée. Par un raccourci de pensée jamais justifié "visuel" était présenté comme synonyme de "supérieur": parce que UML permettait de modéliser visuellement, il était un meilleur véhicule pour parler de conception. Corollairement, le code source lui-même, n'étant que textuel, ne pouvait pas être un support approprié pour exprimer des notions de conception.

Le succès des approches Agiles a contribué à remettre les pendules à l'heure. Toutes les modalités d'expression - visuelles, textuelles, ou autres - ont leur place pour parler de conception. La question est moins de savoir comment représenter le résultat des activités de conception, mais plutôt de savoir qui doit y participer, et par conséquent où elles doivent se dérouler. L'approche privilégiée par les équipes agiles est celle de la "modélisation agile" ou des "sessions rapides de conception": cela se passe au tableau blanc, on doit impliquer les développeurs chargés de la réalisation, et s'il faut conserver une trace permanente une photo du tableau suffit largement.

La conception n'est pas nécessairement une activité qui précède la programmation. Avec UML c'est aussi une approche en phases du projet de développement logiciel qui prévaut. L'accent a été mis sur des outils permettant aux architectes de réaliser un document de conception détaillé en amont du développement, et (comme on dit alors) de le "balancer par-dessus le mur" aux programmeurs qui doivent en suivre les recommandations. C'est une vision caricaturale et inefficace des activités de conception qui n'a que peu de rapport avec la réalité du terrain.

La démonstration en est faite par Fowler lui-même dans son ouvrage sur le Refactoring, dont le sous-titre est "améliorer la conception d'un code existant". C'est un travail rigoureux, argumenté, basé sur un travail de thèse doctorale, celle de Bill Opdyke; il amène Fowler à prédire, et l'avenir lui donnera raison, l'intégration du refactoring automatisé dans les éditions futures des outils de développement.

La conception est une activité collective, pas exclusivement individuelle. Le discours sur la conception est dominé par la description de principes, d'heuristiques, de règles. Grammaticalement, la forme la plus usitée est celle de l'impératif: "évitez les classes contenant un trop grand nombre de méthodes publiques". On n'y prend presque pas garde mais une hypothèse, implicite et jamais remise en question, sous-tend la quasi totalité de ce discours: il s'adresse à une seule personne (Le Concepteur), travaillant de manière isolée. Elle se confirme facilement en examinant des sites d'entraide du type StackOverflow: les questions sont systématiquement de la forme "Comment dois-je m'y prendre pour..."

L'approche Agile suggère une autre démarche, dans laquelle le "nous", le collectif, l'équipe prennent le pas sur l'individu. La question n'est plus "quelle est la bonne conception dans cette situation", mais "sur quelle conception pouvons-nous être d'accord". Non pas "quel principe de conception prévaut", mais "quels critères nous permettent de décider entre deux propositions individuelles (ou mieux encore en faire la synthèse)".

L'enjeu de la conception n'est pas, d'une façon un peu scolaire, de donner individuellement la réponse correcte; il est pragmatique et économique, et consiste à générer plusieurs propositions et décider, entre ces diverses alternatives, laquelle offre les conséquences les plus désirables pour le projet. Cette décision engage la responsabilité de chacune des personnes qui devront ensuite assurer la maintenance du code, elle est donc une négotiation collective... sans pour autant être nécessairement égalitaire: les compétences en matière de conception ne seront que rarement partagées dans l'équipe de façon homogène.

Changer de point de vue

Sur ces trois points au moins, le discours Agile a contribué à chasser les images d'Epinal de la conception et rétablir une perception plus juste de cette activité. Reste que ces trois erreurs avaient à mon sens une origine commune, l'erreur de projection que je dénonçais dans un précédent billet: et malheureusement, y compris au sein de la communauté Agile, nous continuons à commettre cette erreur en parlant exclusivement de propriétés du code telles la duplication, la complexité, les heuristiques SOLID, les métriques de conception, etc.

Tout comme la dette technique, la conception, bonne ou mauvaise, n'est pas exclusivement une propriété du code source (ou des documents et autres artefacts qui l'entourent), et se focaliser sur les produits de l'activité de développement, c'est faire l'impasse sur la moitié de la question: le fonctionnement cognitif humain et ses limites.

Des bugs dans le cerveau aux bugs dans le code

Pourquoi est-il si difficile de créer du logiciel sans bugs? Probablement en grande partie parce que l'outil principal que nous utilisons est lui-même un très mauvais exemple de conception rationnelle, et pour cause, et quand on y regarde de près s'avère bourré de bugs.

Cet outil, c'est le cerveau; ou si l'on veut, mais en ne le prenant que comme une métaphore, le logiciel, appelé "Intelligence", que nous faisons tourner sur le matériel qu'est le "Cerveau". (Faire le parallèle entre l'esprit-logiciel et le cerveau-matériel, c'est en soi rentrer dans la vaste controverse de l'intelligence artificielle, et ce n'est pas mon propos.)

La Loi des Bugs

Je ne suis pas loin de penser que l'énoncé suivant est une loi fondamentale du développement:

Il n'existe de bugs dans nos programmes qu'en raison de bugs dans notre pensée.

Le terme "bug" est en soi un choix terminologique malheureux, c'est un excellent exemple de la psychologie de la projection que j'évoquais dans un précédent billet: on visualise une petite bestiole dont l'existence et les décisions sont autonomes et indépendantes de notre volonté. Je lui préfère en général le terme "défaut", qui indique plus clairement ce qui est, selon moi, toujours à l'origine de ce qu'on appele familièrement un bug: une erreur du programmeur, se traduisant par un code source qui spécifie un comportement différent de ce qu'il devrait être.

Mais c'est au moins un terme familier, et si vous dites à quelqu'un "tu ne t'en aperçois pas mais ton cerveau est plein de bugs", vous êtes au moins sûr de faire une forte impression.

Biais cognitifs

L'étude des bugs du cerveau relève de la psychologie, et le terme plus communément accepté est celui de "biais cognitif". Contrairement à la situation qui prévaut dans le domaine du logiciel, les sciences cognitives ont produit, s'agissant des biais cognitifs, des connaissances scientifiques démontrées de façon robuste, répétable, qui ne sont plus affaire d'opinion. Indépendamment de ce que je voudrais croire ou de mes bonnes intentions, je suis bien contraint de reconnaitre que mon cerveau, à peu de choses près dans la même mesure que celui de mes congénères, est sujet à un certain nombre de biais cognitifs.

Intéressons-nous par exemple au biais de confirmation. Nous allons voir que ce phénomène, qui est par ailleurs l'un des plus importants et sournois dans la psychologie humaine, est tout à fait pertinent pour éclairer notre approche du développement logiciel.

Il est mis en évidence par de nombreuses expériences dont les premières remontent aux années 1960 avec les travaux de Peter Wason.

Wason montre à ses sujets un triplet composé de trois chiffres: (2, 4, 6) et indique que ce triplet répond à une "règle de construction" qu'il s'agit de deviner. Il demande aux sujets de lui fournir des exemples supplémentaires afin de "tester" diverses hypothèses quant à l'énoncé de cette règle. L'expérimentateur se borne à donner une réponse binaire: "oui, votre exemple est conforme à la règle" ou bien "non, votre exemple n'est pas conforme". C'est donc une tâche inductive, très ouverte par nature.

En étudiant de près les hypothèses formulées par les personnes confrontées à cet épreuve et les "essais" fournis successivement, Wason est en mesure de démontrer une tendance tout à fait systématique: on propose beaucoup plus facilement des exemples "de confirmation", c'est-à-dire conformes à l'hypothèse qu'on a la plus récemment formulée. Or c'est une erreur, car si des exemples confirmés peuvent nous amener à valider une réponse avant de la proposer, la démarche la plus fructueuse consiste à proposer des exemples qui (s'ils sont acceptés par l'expérimentateur comme conformes à la règle) invalident notre hypothèse et nous forcent à la reformuler.

D'autres expériences de Wason conforteront le "biais de confirmation" comme une erreur de raisonnement tellement courante qu'on peut la considérer comme systématique chez l'être humain: ainsi sur une tâche consistant à déterminer lesquelles parmi quatre cartes on doit retourner pour vérifier une règle du type "SI telle figure apparaît au recto ALORS telle autre doit apparaître au verso", seuls 10% des sujets donnent la bonne réponse! Ceci alors que plus de 90% des sujets reconnaissent, une fois qu'on leur a donné cette réponse, qu'elle est effectivement correcte et qu'ils pouvaient logiquement le déterminer à la lecture de l'énoncé: ce qui écarte donc l'hypothèse d'une ambiguité ou d'une mauvaise compréhension de la tâche.

(Si vous êtes tenté à la lecture de ce billet de développer vos propres facultés en matière d'induction et de formulation d'exemples contradictoires, essayez le jeu Zendo, passionnant pour les petits et les grands...)

Application au développement

Revenons au développement de logiciels, et plus précisément à un des épisodes de l'historique du génie logiciel. En 1976, Glenford Myers, auteur de l'ouvrage de référence "Software Reliability, Principles and Practices", écrit ceci:

Il est impossible de tester vos propres programmes. Aucun programmeur ne devrait tenter de tester son propre programme. Ceci s'applique à toutes les formes de test, que ce soit le test système, fonctionnel ou le test unitaire. [...] Le test doit être une activité extrêmement destructrice, et il est des raisons psychologiques profondes qui empêchent le programmeur d'adopter une attitude destructrice vis-à-vis de son propre programme."

Les mots employés sont très forts: "impossible", "toutes les formes de test". Myers ne cite pas Wason et ne détaille pas dans cet ouvrage les "raisons psychologiques profondes" auxquelles il fait allusion, mais il semble clairement s'agir de notre tendance à imaginer plus facilement des jeux d'essais qui visent à confirmer nos hypothèses que ceux pouvant les infirmer. (Il existe d'ailleurs quelques études cherchant à démontrer directement l'impact du biais de confirmation sur l'incidence des défauts dans le code.)

Cette affirmation que Myers présente comme un "axiome" deviendra pendant de nombreuses années l'orthodoxie en matière de test logiciel. (Une recherche Google avec la phrase "test their own code" donne assez facilement des exemples récents de billets d'opinion reprenant sans la critiquer cette idée, comme si elle allait de soi.)

En un sens, cette affirmation a eu un effet positif: elle a favorisé l'apparition d'une sous-discipline, le test indépendant, dont l'apport est certainement bénéfique; bien qu'en France la culture soit apparemment bien moins sensible à l'intérêt d'employer des personnes dans un rôle dédié de "testeur" ou "assurance qualité", par rapport aux Etats-Unis.

TDD ou l'inversion géniale

Pourtant, je soupçonne cette attitude d'avoir également généré de sérieux dégâts, en berçant d'innombrable développeurs dans la douillette illusion que "tester leur propre code" était non seulement une erreur mais une faute professionnelle. Pensez-y la prochaine fois que vous rencontrez sur un site Web une NullPointerException, l'exemple par excellence d'une défaillance logicielle qu'on peut parfaitement éviter en testant plus soigneusement son code.

Les choses n'ont commencé à changer que relativement récemment, et grâce à l'introduction de la pratique agile du Développement par les Tests (ou TDD).

Il s'agit pour moi (et pour d'autres, comme Steve McConnell dans Code Complete) de l'une des contributions majeures de la mouvance Agile à ce qu'il faut bien encore appeler le génie logiciel. Depuis les années 2000 le discours autour de cette pratique a considérablement évolué en sophistication, mais l'idée élémentaire est restée la même.

Elle exploite la notion d'un test unitaire automatisé, c'est-à-dire un bout de code qu'on écrit uniquement pour mettre en évidence qu'un autre bout de code (celui-là utilisé directement dans le programme réel) fonctionne comme attendu. Il va de soi qu'un test unitaire automatisé, en soi, reste un "test", un "essai" qu'on confronte à une hypothèse: l'automatisation ne change rien de fondamental.

Ce qui est radical, c'est l'idée suivante:

écrire le test avant d'écrire le code correspondant

Cela n'a l'air de rien mais cette simple inversion suffit simultanément:

• à donner raison à Glenford Myers sur l'importance du biais de confirmation en matière de test
• à lui donner tort sur les conclusions: un développeur peut et doit tester son code

En effet, avant d'avoir écrit un élément de programme, nous ne sommes pas sujets au biais de confirmation, puisque nous ignorons encore les détails de l'implémentation. Ces détails fonctionnenent en programmation comme l'hypothèse à tester dans la tâche de Wason: si nous avions connaissance de notre implémentation, nous serions tenté de ne penser qu'à des jeux d'essais qui confortent l'impression que nous avons que notre code est correct.

En inversant l'ordre de marche, nous avons tenu compte de nos propres limitations cognitives, et nous leur avons apporté une solution nettement plus efficace, car nécessitant moins de coordination, que la solution classique "embaucher des testeurs indépendants pour tester le code mal fichu des développeurs". (Cette dernière solution garde cependant de son intérêt, car il existe bien d'autres aspects de la qualité logicielle qui peuvent bénéficier du travail d'un testeur que la seule qualité technique du code source.)

Conclusions

Ce premier exemple donne une perspective un peu différente sur le TDD que celle habituellement présentée, et surtout démontrant à quel point s'intéresser au développement logiciel par le biais des sciences cognitives, et notamment par celui des biais cognitifs, peut être puissant et fructueux.


L'approche usuelle du génie logiciel a été d'écarter systématiquement ces considérations, qui reposent pourtant sur des bases scientifiques robustes, pour ne considérer que les aspects "objectifs" du logiciel, vu comme une "chose naturelle" indépendante de l'esprit humain qui l'a créé: c'est pourquoi, à mon sens, cette discipline telle qu'elle a été conçue jusque là ne peut pas résoudre les difficultés qu'elle prétendait aborder. Pour progresser, il est impératif de tenir compte des aspects cognitifs qui jouent un rôle déterminant dans la création de logiciels.

Le champ d'application de cette démarche va bien au-delà de la technique, on peut lui trouver des applications dans la gestion de projet, la gestion des compétences, l'estimation des délais, bref à l'ensemble des préoccupations des professions du logiciel.

Reykjavik, Prezi, conception Agile

Jeudi prochain, destination: Reykjavik! Le choix du coeur, ayant beaucoup apprécié l'Islande lors de vacances passées là-bas il y a deux ans, et promis d'y revenir; mais également un coup de pouce à une communauté Agile très dynamique.

J'avais bien apprécié l'atelier sur la pensée visuelle proposé par Benoit Gantaume (Agilidée, partenaire de l'Institut) lors de l'étape Nancéenne de l'Agile Tour et je m'étais promis de mettre en oeuvre les outils présentés à l'occasion d'un exposé pour une conférence.

La session avec laquelle je "tourne" actuellement, "Quarante ans de crise, dix ans d'agilité, et après" est largement constituée des sujets que j'ai traité récemment sur ce blog, qui proviennent eux-mêmes des réflexions qui ont motivé le lancement de l'Institut; elle n'est pas vraiment pertinente pour mes amis Islandais (et une précédente expérience m'a appris que le caractère Nordique peut être impatient avec ce qui ne lui semble pas pertinent: c'est mon unique et cuisant souvenir d'un exposé où une bonne partie de la salle a "voté avec ses pieds").

J'avais donc proposé un sujet sur les pratiques Agiles liées à la conception. Je souhaitais apporter une perspective un peu différente sur ce sujet: que nous a appris le mouvement Agile sur la conception, quelles pratiques sont utiles dans ce domaine et pourquoi, comment la prise en compte du non-technique et du "facteur humain" en Agile éclaire-t-elle notre compréhension de cette activité, vers quels sujets scientifiques nous pousse-t-elle à nous intéresser?

Depuis quelque temps je voulais aussi sortir de l'ornière "PowerPoint" (en l'occurrence Keynote puisque je suis un "Apple fanboy", mais c'est du pareil au même) mais je ne me sens pas encore à l'aise, lorsque j'aborde des sujets un peu théoriques, avec un exposé sans aucun support visuel. D'expérience, mon auditoire est composé de personnes ayant des préférences cognitives diverses: certains sont plutôt visuels, d'autres plutôt auditifs, d'autres kinesthétiques. Je cherche à présenter le même contenu sous plusieurs formes pour m'assurer que le maximum de personnes en retirent l'essentiel.

J'avais entendu parler de Prezi (et vu une présentation de Jonathan Perret utilisant cet outil à Agile France 2010), j'ai saisi l'occasion pour expérimenter.

Mon retour, façon Perfection Game: j'attribue largement 6/10, Prezi tient ses promesses de dépasser le carcan suranné du "slideware" directement hérité du projecteur de diapos (que mes parents avaient rangé dans un placard pour ne jamais le ressortir alors que j'avais, disons, 8 ou 10 ans). A la place, et après un démarrage très déroutant, on goûte un vrai sentiment de liberté devant le canevas sans limite et la possibilité de zoomer en avant, en arrière à l'infini (presque, j'ai réussi à me faire taper sur les doigts parce que ma présentation commençait à faire concurrence à "powers of ten" en termes de niveaux parcourus). On se sent vraiment incité à penser visuellement, à organiser spatialement des idées jetées pèle-mèle, à les hiérarchiser par la taille. Je me suis même pris à créer des jeux de mots visuels, alors que c'est tout sauf mon langage de prédilection!

Pour avoir 10/10 il faudrait corriger quelques défauts d'ergonomie, mineurs et pas bloquants mais très, très frustrants par moments; il faudrait pouvoir copier-coller plus facilement entre présentations (à mon avis Prezi a loupé une grosse occasion d'exploiter la dimension "sociale" de leur outil, en encourageant les auteurs à se piquer des éléments réutilisables); il faudrait un peu plus de liberté dans le choix des polices et des couleurs de fond.

Mon premier Prezi est en ligne (c'est la règle du jeu, la gratuité de l'outil est au prix du partage, je trouve ça très bien mais encore une fois on peut regretter que ça ne soit pas mieux exploité), si vous avez envie de jeter un coup d'oeil, vos retours seront les bienvenus.

La danseuse et la dette technique

Une "danseuse", dans l'expression héritée du XIXè siècle, désignait une maîtresse qu'on entretient à grand frais, et par extension un projet, une habitude auxquels on consacre une dépense excessive pour des raisons largement affectives et peu utilitaires.

L'expression m'est revenue à l'esprit en réfléchissant à une conversation récente sur la "dette technique", le terme consacré pour désigner des logiciels dont le code source est mal fichu, à tel point qu'ils deviennent de plus en plus difficiles à faire évoluer. J'ai connu des projets de ce type, et j'ai été frappé de leur côté "danseuse": ce sont des projets sur lesquels on investit beaucoup d'argent, mais dont on retire très peu de profit; pourtant on ne se résigne pas à s'en séparer.

L'une des difficultés est que les conséquences de la "dette technique" se font sentir de façon très tangible, mais la "dette" elle-même n'est pas visible, on ne sait pas la mesurer. Dès lors il est difficile de justifier des décisions radicales, puisqu'elles vont s'appuyer non pas sur des éléments objectifs mais sur le ressenti des développeurs. "La dette technique est trop élevée, on ne peut plus continuer!" - "Ah bon, à combien la chiffrez-vous?" - "Euh... on ne sait pas... mais c'est trop."

Surgit alors une idée: pouvons-nous trouver des outils d'analyse du code qui vont nous permettre de mesurer la dette technique? Idée lumineuse sur le papier: non seulement elle va nous permettre d'objectiver quelque chose de flou et subjectif, mais en plus nous pourrions installer de tels outils dès le début du projet et ainsi éviter la dérive de la dette, en conserver le contrôle en permanence.

Malheureusement, je crains que cette idée ne soit un miroir aux alouettes. Ce n'est pas que de tels outils soient inutiles; mais s'appuyer exclusivement sur eux révèle une incompréhension majeure de ce qu'est la dette technique, en présence de laquelle leurs résulats seront inexploitables. Pour résumer en quelques mots, la dette technique n'est pas dans le code, elle est entre le code et ceux qui l'entretiennent. Pour bien expliquer cette thèse je vais devoir faire intervenir... une autre danseuse.

L'autre danseuse

Regardez bien l'image animée ci-dessous.

Dans quel sens voyez-vous tourner la danseuse? De la gauche vers la droite, ou l'inverse? Dans un cas comme dans l'autre, si vous continuez à vous concentrer sur l'image pendant un moment, il y a de grandes chances pour que vous voyez ce sens de rotation s'inverser subitement, un effet visuel qui perturbe un peu: on se persuaderait facilement qu'il y a tromperie quelque part, que c'est l'image qui a changé et pas simplement notre perception de l'image. (Je connais des gens qui après avoir vu cette image ont passé un temps considérable à l'analyser avec Photoshop pour trouver "l'astuce". Il n'y a pas d'astuce.)

La réalité est que cette animation fait partie de la même catégorie d'illusions d'optique que le fameux cube de Necker, celle des images ambigues. L'effet de silhouette supprime de l'image toutes les informations liées à la profondeur, et met sur un même plan tous les éléments d'anatomie, bras, jambes, cheveux, de sorte qu'il n'est tout simplement pas possible de savoir quel sens de rotation est "réellement" indiqué par l'image.

Pourtant notre cerveau insiste: il ne peut pas tolérer l'ambiguité, il est donc obligatoire de voir la danseuse tourner dans un sens ou dans l'autre. Nous avons la sensation irréfutable que le mouvement est dans l'image, pas dans notre esprit.

Projection

Cette sensation correspond à une classe de phénomènes cognitifs appelés "projection". Une projection, de manière générale, est une opinion ou une croyance qui ne regarde que nous mais que nous interprètons comme une réalité extérieure.

Par exemple si je me promène le soir dans un quartier qui a une réputation "chaude", je ressens de l'inquiétude, et puis je vois arriver deux personnes qui parlent fort, je me dis "Ces gars-là ont l'air vachement aggressifs, sûrement des voyous" et m'enfuis en courant devant deux passants tout à fait normaux mais médusés...

Localiser la "dette technique" seulement dans le logiciel relève de la projection. En fait la dette technique est un concept intrinsèquement relationnel, c'est un rapport entre des gens (une équipe de développement par exemple) et une collection d'artefacts logiciels dont du code source. La question qui se pose est "quels freins ces personnes rencontrent-elles quand elles cherchent à intervenir sur ce logiciel", est-ce qu'elles trouvent leur chemin, est-ce qu'elles sont forcés à du travail inutile, etc.


Bonne dette, mauvaise dette...

Par exemple on dit qu'un des éléments majeurs de la dette technique c'est la duplication de code. Mais si on y réfléchit plus précisément, on se dit que le code est toujours dupliqué en plein d'endroits: chaque programmeur en a une copie intégrale, grâce à la gestion de versions! Et ça ne gêne personne, ce n'est pas de la dette, parce que l'outil gère très bien cette duplication. Donc il y a de la duplication qui n'est PAS de la dette technique. C'est comme le cholestérol en somme, il y a le bon et le mauvais...

La mauvaise duplication par exemple, c'est quand d'autres programmeurs ont fait du copier-coller et que le taux de TVA à 18,6% se retrouve partout dans le code. Quand il passe à 19,6%, ça prend plus de temps de faire une recherche et un remplacement globals que si on pouvait simplement modifier le chiffre à un endroit unique dans le code. Et imaginez qu'en plus du copier-coller il y a des programmeurs qui ont écrit 0,186 à un endroit, 18,6 à un autre, 1,186 à un troisième: des variantes multiples qui font que rechercher-remplacer ne marche pas.

La dette technique est faite de difficultés de ce type, des ruptures entre le modèle métier et son expression dans le code, ou bien des hypothèses non explicitées qui ne se révèlent que quand elles changent, et on se retrouve coincé: mais on se retrouve coincé par rapport aux outils dont on dispose ou par rapport à un niveau de compétence ou par rapport à un état de connaissances de l'équipe.



La dette est dans l'interaction
 
Il n'y a pas dans l'absolu de dette technique dans le code. Pour mesurer la dette, il faut penser en termes d'observation des interactions entre les gens et le code.

On peut réfléchir à des métriques "objectives" telles que la complexité cyclomatique, mais ce qui est déterminant c'est la façon dont l'esprit humain appréhende le code pour le modifier, et ce qu'il faut donc expliciter, c'est ce que ces métriques peuvent avoir comme relation avec l'exécution par le programmeur des tâches courantes. Or c'est un sujet largement ignoré; la faute à notre tendance fâcheuse à la projection...

Une Revue des Logiciels et Projets Agiles?

Il m'est arrivé de parler à des collègues chercheurs dans le milieu universitaire, aussi bien en France qu'à l'étranger, et de leur poser la question: "Comment se fait-il qu'on voit si peu de recherche spécifiquement sur les approches Agiles?" J'en connais plusieurs qui s'y intéressent et travaillent "officiellement" sur des sujets connexes, par exemple en génie logiciel. Mais ils ne publient pas ou peu d'études visant à analyser précisément telle ou telle pratique, tel ou tel discours porté par la communauté Agile.

Quand je m'en étonne, ils me font remarquer la chose suivante: pour un scientifique, un critère d'évaluation important de son travail est la production de publications acceptées par des revues réputées dans son domaine. Produire un "papier" qui ne trouverait pas un débouché dans une publication reconnue comme ayant un caractère scientifique constituerait un travail en pure perte. (Dans le secteur privé, un chercheur est un salarié, il ne rend finalement de comptes qu'à son employeur, et pour peu qu'il ait un manager éclairé il se verra imposer peu de contraintes. Il est possible que cette tyrannie des "bonnes" revues pour publier soit moins contraignante dans ce contexte.)

Il n'existe pas, à ma connaissance, de revues scientifiques spécifiquement consacrées à l'etude des pratiques Agiles. Par conséquent, on ne publie pas sur ce sujet. Mais, bien évidemment, l'absence de travaux dans ce domaine contribue à pérenniser la fracture entre recherche et industrie, ce qui fait que les intervenants des projets Agiles pensent que le travail des chercheurs ne les concerne pas. L'industrie n'en faisant pas la demande, la recherche de son côté continue à ne pas s'intéresser à ce sujet, et a peu de chance de vouloir reconnaître sa pertinence. Cela ressemble pas mal à un cercle vicieux!

Pourtant on peut facilement se convaincre qu'un canal de publication de ce type est nécessaire.

Le modèle consacré est celui de l'évaluation par les pairs ("peer review"), les publications se dotant d'un comité de lecture dont le rôle est de filtrer les travaux proposés pour veiller à ce que ce qui est publié répond à des critères de qualité spécifiques: il s'agit en fait d'assurer la bonne "circulation des références" comme l'a analysé Bruno Latour, vérifier par exemple que les chercheurs sont au courant des travaux précédemment effectués dans leur domaine, les référencent et les sites, que leurs études permettent de combler les lacunes de ces antécédents et ainsi consolider les connaissances.

Ainsi beaucoup de travaux portant sur des sujets tels que le développement par les tests ou la programmation en binômes souffrent d'un travers élémentaire: ils sont réalisés par des chercheurs qui utilisent leurs propres étudiants comme sujets d'étude. Mais, par définition, il s'agit d'une population non pas de programmeurs en exercice, mais de programmeurs en devenir! Pire encore, le protocole expérimental prévoit généralement un temps ridiculement court pour former ces sujets d'étude à la pratique dont on cherche à discerner les bénéfices.

On va donc passer une après-midi ou une journée à expliquer le développement par les tests (TDD) à des étudiants, puis comparer leur performance à celle d'autres étudiants, la condition expérimentale consistant pour l'essentiel à ce qu'un des deux groupes reçoit l'instruction "utilisez ce qu'on vous a appris". Quelle que soit la rigueur de l'analyse statistique qui vient ensuite, il est impensable de tirer de telles études la moindre conclusion définitive quant à l'intérêt que le TDD peut avoir en entreprise. Et ces études, même quand on les qualifie prudemment de "préliminaires", sont rarement suivies de nouvelles visant à corriger ces lacunes. Pour la simple et bonne raison qu'intervenir en entreprise coûte plus cher, et exige de surmonter la réticence, compréhensible mais pas nécessairement appropriée, de ces dernières à inviter des chercheurs dans leurs bureaux pour regarder de près ce qui s'y passe.

Fédérer en réseau les chercheurs qui oeuvrent dans ce domaine, et à terme contribuer à la création d'une telle revue, est une mission tout à fait naturelle pour l'Institut Agile. L'objectif est de produire des connaissances affranchies des opinions et idéologies qui soient utiles aux intervenants des projets Agiles.

Le social a plus d'influence sur les bugs que la technique

On peut penser ce qu'on veut de Microsoft en tant qu'entreprise, force est de constater que l'éditeur offre un terrain propice à l'étude à grande échelle des réalités du développement logiciel; et que les moyens financiers de Microsoft lui servent entre autres choses à financer une recherche privée d'un excellent niveau. L'exemple emblématique pour moi en est Nachi Nagappan, dont les travaux me fascinent.

Nagappan a repris un sujet d'étude assez ancient, la notion de susceptibilité aux bugs ("defect proneness"). Si vous découpez un logiciel en modules, et que vous comptez à l'issue d'une analyse raisonnablement rigoureuse quels modules font l'objet du plus grand nombre de corrections de défauts, vous vous rendrez compte que tous les modules ne se valent pas. Certains accumulent les casseroles, pour ainsi dire. On peut donc se demander s'il existe des régularités qui caractériseraient les modules les plus (ou les moins) susceptibles de contenir des défauts, de façon par exemple à guider le travail des testeurs.

On a beaucoup étudié les corrélations avec des mesures techniques, comme l'analyse des dépendances ou la complexité cyclomatique. Nagappan relève que c'est ignorer totalement l'aspect humain; on fait comme si le logiciel était en soi quelque chose d'objectif, une "chose" qu'on trouve telle quelle dans la nature et qu'on examine à la loupe comme un caillou ou une plante. Or ce qui est le plus important dans l'histoire c'est qu'un module ou un logiciel est produit par une organisation d'individus.

Nagappan et ses collaborateurs se sont donc penchés sur des "métriques" caractérisant l'organisation sociale des équipes responsables de divers modules dans le code, proprement garguantuesque, du système Windows 7. La culture d'entreprise de Microsoft offre un environnement relativement homogène, dans lequel des équipes bien identifiées s'occupent de modules bien identifiés, le terrain est donc favorable à une étude comparative qui analyse des caractéristiques relativement stables des équipes et des modules logiciels concernés.

Le résultat obtenu fait réfléchir (mais est-il vraiment surprenant): les paramètres "sociaux" sont plus pertinents que les paramètres "techniques" pour prédire quels modules sont les plus susceptibles de contenir des défauts.

Comme je l'ai dit précédemment il convient de rester critique, et le travail de Nagappan mobilise des outils statistiques et des critères d'évaluation ("précision" et "rappel") que je ne maîtrise pas, il me manque donc (pour l'instant) la culture nécessaire pour évaluer ces résultats.

Il me semble cependant qu'ils sont sur une bonne voie, qu'ils posent les bonnes questions.

Un petit jeu de "Cinq Pourquoi"

Hier matin j'ai eu le plaisir d'une discussion autour d'un café avec Hugo Heitz, responsable du déploiement Lean dans le département Exploitation d'une grande banque, dont j'avais bien apprécié l'intervention lors d'un précédent séminaire consacré à l'approche Lean, et avec qui je suis resté en contact depuis.

A un moment la conversation a abordé les difficultés liées à la "dette technique", l'entropie qui semble frapper inexorablement tous les projets informatiques avec pour conséquences qu'après un temps plus ou moins long (trop souvent assez court), des évolutions qui auraient été considérées comme mineures en début de parcours deviennent de plus en plus coûteuses, laborieuses, pénibles à réaliser comme à négocier.

Nous avons des constats très similaires malgré nos perspectives différentes, Hugo oeuvrant dans le domaine de l'exploitation, alors que je m'intéresse au développement; les deux mondes sont inexorablement liés mais semblent ne pas vouloir reconnaître leur existence mutuelle. (En plaisantant j'ai fait allusion à H.G. Wells pour décrire ce qui semble se passer entre ces deux populations: les "Morlocks de l'informatique" faisant un travail souterrain et ignoré tandis que les "Eloi du logiciel" mènent une vie insouciante. Evidemment ça nous a amenés à nous demander si de temps en temps un Eloi se faisait manger...)

Nous nous sommes alors lancés, presque sans le remarquer, dans un petit jeu des "cinq pourquoi", un des outils Lean qui a été assez joyeusement repris par les équipes Agiles. Pourquoi les projets finissent-ils par s'engluer, que ce soit du côté développement ou du côté exploitation? Parce que cette "dette technique" est composée de logiciel, et que le logiciel est par nature invisible, contrairement au hardware. On peut plus facilement mesurer l'âge moyen d'un parc matériel vieillissant et convaincre par des chiffres qu'il est temps d'investir, mais comment mesurer la "dette technique" logicielle?

Alors pourquoi cette "dette technique" est-elle si difficile à mesurer? Parce que les programmeurs (je parlais alors pour ma partie) investissent leurs efforts sur les mauvaises priorités. "Pas le temps de mettre ce code au propre, il faut qu'on livre de nouvelles fonctionnalités." Et pourquoi les programmeurs ne se rendent-ils pas compte que ces choix sont contre-productifs? Parce que bien souvent il leur manque certains savoirs et savoirs-faire qui leur permettraient d'objectiver et d'argumenter en faveur de décisions plus appropriées. Pourquoi leur manque-t-il ces connaissances?

A ce moment nous n'avions posé que quatre "pourquoi" (et il faudra sans doute un jour creuser plus loin) mais nous sommes tombés d'accord sur un constat: tant que la formation des personnes entrant dans les métiers de l'informatique ne les prépare pas à imposer dans leurs entreprises des pratiques plus efficaces, il sera difficile d'espérer des améliorations.

En France les cursus de formations supérieures sont indissociablement liés aux organismes publics de recherche, la recherche en entreprise étant moins développée dans l'informatique que dans d'autres secteurs économiques; c'est donc à mon avis vers les enseignants-chercheurs qu'il est important de se tourner pour trouver des réponses.

Or la collaboration entre les professionnels en entreprise et ce monde de la recherche et de l'enseignement publics me semble extrêmement marginale, presque inexistante. C'est vrai de manière générale pour ce qui concerne le génie logiciel: combien de développeurs ou de chefs de projet travaillant en entreprise s'intéressent au travail des chercheurs dans ce domaine et les trouvent pertinents et concrètement utiles? Le seul domaine que je connaisse où il semble qu'une collaboration fructueuse se soit établie est celui de la "programmation par les modèles" ou "model driven".

Concernant les approches Agiles, c'est carrément le désert. Un exemple: il existe des projets de recherche à l'échelle européenne, par exemple le programme ITEA2. Ces projets mutualisent des investissements publics et privés en R&D et visent à rendre l'Europe plus compétitive dans ce domaine. Au sein d'ITEA2, il existe un sous-projet FLEXI réunissant des chercheurs en un réseau qui cible spécifiquement des pratiques Agiles. On n'y trouve... aucun partenaire industriel français, et apparemment aucun chercheur français.

Le projet de l'Institut Agile prend très au sérieux ce rapprochement nécessaire entre le milieu de la recherche et de l'enseignement d'une part, et la communauté Agile et ses professionnels d'autre part. Rendre compte de la recherche sur les différentes pratiques est par exemple un des objectifs du référentiel.

Il faut aller plus loin. J'ai publié aujourd'hui un premier appel en vue du recensement des chercheurs en France (ou dans la sphère francophone plus largement) qui s'intéressent à ce sujet. Si vous exercez vous-même des activités d'enseignement et de recherche, je vous encourage vivement à vous inscrire; si ce n'est pas le cas, à diffuser autour de vous l'adresse de cette page.

L'objectif dans un premier temps est de mieux connaître et mieux faire connaître cette partie de la communauté Agile. Travailler ensemble, c'est pouvoir mieux faire valoir l'intérêt de ces recherches, à la fois envers les organismes habilités à financer et favoriser des projets de recherche, mais aussi et surtout en direction des développeurs, chefs de projets et autres intervenants sur les projets Agiles.

Folklore ou fait scientifique, comment les différencier

Ce qui est ennuyeux avec les opinions, c'est que chacun a la sienne. Et vous trouverez tout et son contraire. "Le développement par les tests élimine les bugs", affirme l'un. "Le développement par les tests fiche en l'air votre architecture", prétend l'autre. La connaissance ne peut pas se diffuser que par le biais des blogs, organes d'opinion s'il en est, faute de quoi tous les débats vont durer éternellement. L'intérêt du travail des scientifiques, c'est de trancher.

Comment fonctionne le discours scientifique

Bruno Latour, l'un des observateurs les plus passionnés du véritable travail que produit la science, et aussi l'un des plus attentifs à le débarrasser de ses mythes et images d'Epinal qui l'entourent, nous donne plusieurs pistes pour mieux évaluer le statut d'une recherche en cours, qui n'a pas encore abouti; ce qu'il nomme une controverse.

(J'ai découvert les écrits de Bruno Latour lorsqu'on m'a recommandé de lire Aramis ou l'Amour des Techniques. Ce livre a totalement changé ma façon de voir les projets informatiques, bien qu'il concerne un autre domaine technologique: les transports en commun. Depuis, je le recommande vivement à tous les chefs de projets, architectes, ingénieurs et managers de mon entourage; c'est un de mes livres indispensables. Il révèle Latour comme un observateur tenace et minutieux, avec une incroyable capacité à aller au fond des choses dans le domaine des sciences et techniques. Il se lit comme un roman, ce qui ne gâte rien.)

Latour attire notre attention en particulier sur la structure modale du discours scientifique. Cette expression barbarbe désigne quelque chose de tout simple. Vous partez d'un simple énoncé: "L'eau bout à 100 degrés." Une modalité est quelque chose qui vient, sans modifier cet énoncé mais en le complétant, lui donner un statut différent: "Si je me souviens bien, l'eau bout à 100 degrés" exprimerait de l'incertitude. "Tout le monde sait que l'eau bout à 100 degrés" au contraire renforce l'autorité du discours. "Les scientifiques savent que l'eau bout à 100 degrés" aurait une connotation légérement différente, celle d'un savoir pas nécessairement partagé par le commun des mortels.

Dans la pratique des sciences, une publication joue le rôle d'une (très longue) modalité. Un chercheur souhaite affirmer une conclusion: "l'eau bout à 100 degrés". Il doit dans un premier temps, c'est la convention de sa profession, la présenter avec des pincettes: "sous réserve des questions de validité soulevées ci-dessus, et au vu de nos mesures expérimentales il nous semble possible d'affirmer que l'intervalle de confiance à 95% situe le point d'ébullition d'H20 à 100 degrés plus ou moins 0,01 dans les conditions expérimentales". Le reste de la publication (du "papier") tient lieu d'autant de précautions qui visent à relativiser l'énoncé final.

Une expérience ou une étude n'étant jamais suffisante pour asseoir un fait scientifique, d'autres "papier" vont poursuivre ces travaux, qu'ils soient écrits par le même chercheur ou par ses confrères. Il faut pour cela que les travaux initiaux soient intéressants, ce qui est souvent un premier filtre; sans doute l'immense majorité des "papiers" publiés n'est jamais cité par d'autres scientifiques. La citation joue donc un rôle capital dans l'acquisition du statut de "fait scientifique".

La citation est elle-même une modalité, souvent complétée par un degré de confiance: "Un travail préliminaire de Dupont (2001) suggère que l'eau bout à 100 degrés. Nous présentons une réplication utilisant un équipement différent mais aboutissant à des conclusions qui semblent confirmer ce résultat, avec une légère variation." L'accumulation des citations d'un "papier" donné est souvent une mesure de son importance, et si l'énoncé fini par se confirmer il établira la paternité du fait en question.

Ce que Latour met en lumière c'est que l'établissement d'un fait scientifique s'accompagne de la disparition progressive des modalités. Ainsi l'étape suivante est-elle: "De nombreuses études ont mis en évidence que le point d'ébullition de l'eau se situe autour de 100 degrés (Dupont 2001, Durand 2002, Dupont 2003, Bogdanoff 2010), mais avec de légères variations; nous montrons que ce point d'ébullition dépend de la pression atmosphérique et selon quelle équation." Un peu plus loin encore, on commence à ne plus citer les auteurs: "Il est désormais établi que l'eau bout à 100 degrés à pression atmosphérique normale; nous étudions les effets de l'adjonction de sel dans l'eau."

Au stade ultime de l'acceptation d'un fait scientifique, celui-ci est d'une part débarrassé de toute modalité ("l'eau bout à 100 degrés") mais plus important encore devient opérationnel pour produire d'autres connaissances, ou des effets techniques utiles: "pour obtenir une température de 100 degrés nous portons de l'eau à ébullition". (Pour des exemples plus réalistes, lisez La vie de laboratoire de Latour et Woolgar.)

Evidemment, ce qui fait de ce jeu de citations une démarche proprement scientifique, c'est son caractère expérimental et contradictoire; cette réduction des modalités n'est pas inexorable, et une étude préliminaire largement citée peut se voir mise en défaut par des études postérieures.

L'autre cas de figure, c'est que le prétendu "fait" ne se débarrasse jamais tout à fait de ces modalités; il reste indéfiniment entâché de soupçon, et si personne ne s'y intéresse assez pour y donner suite dans de nouvelles publications, il tombe dans l'oubli, ou pire, s'incruste dans le discours collectif à l'état de folklore.

Que sait-on sur la productivité des programmeurs?

Prenons par exemple un "fait" largement cité dans le monde informatique, celui selon lequel "la productivité des programmeurs varie dans un rapport de 1 à 10 (ou 5, ou 20) entre les moins bons et les meilleurs". C'est un énoncé surprenant, ne serait-ce que pour ses implications en entreprise: les écarts de salaires entre programmeurs, par exemple, ne sont certainement pas de cet ordre.

A quand remonte cet énoncé? Coincidence amusante, la première étude à faire état de ces disparités remonte apparemment à 1968. C'est une "vraie" étude scientifique, qui au départ cherche à comparer, dans deux conditions expérimentales, la performance de programmeurs confrontés à une tâche de mise au point (debugging). Les temps de programmation sont collectés au cours de l'étude mais n'en sont pas le sujet principal. L'étude trouve de façon statistiquement significative que l'une des deux conditions de travail ("online" c'est à dire en mode interactif avec le compilateur) améliore légèrement la performance. Elle note par contre comme une observation surprenante la très grande magnitude des écarts entre les "scores" obtenus par les différents sujets de l'étude, sur diverses mesures de performance.

Cette étude fait rapidement l'objet de diverses critiques, à la suite desquelles on pourrait penser que d'autres recherches vont tenter de confirmer ou d'infirmer ces observations, activité dont on devrait retrouver, quarante ans plus tard, des traces conformes à ce qu'explique Latour: réduction des modalités et transformation en "fait scientifique".

En fait il n'en est rien. Aussi surprenant que cela puisse paraître, quarante ans après le résultat initial, l'énoncé reste aujourd'hui accompagné de ses modalités: chaque fois que j'ai l'occasion de lire ou d'entendre cette observation, c'est sous la forme "de nombreuses études montrent que la productivité varie dans un rapport de 1 à 10 (ou 5, ou 20)".

Non seulement il n'a pas perdu ses modalités, mais ce "fait" ne s'est toujours pas transformé en quelque chose d'opérationnellement utile. On ne sait pas aujourd'hui comment exploiter cette "trouvaille", par exemple en définissant des critères de recrutement qui nous permettraient d'écarter les programmeurs "fois 1" et garder préférentiellement les "fois 2 à 10". Par contre, personne ne se prive de citer cette "observation" pour étayer un discours essentiellement idéologique: "de nombreuses études montrent ceci, donc vous devriez suivre mes conseils".

Comment tricher avec les citations

L'un des essais les mieux renseignés sur le sujet est celui de Steve McConnell, "The Origin of 10x". Publié en 2008, ce billet publié sur son blog explique le titre de ce dernier, "10x programming". Il s'agit bien entendu d'une référence aux variations de productivité. McConnell reconnaît que l'étude de 1968 a été très critiquée, mais il affirme que ses résultats ont été confirmés:

the general finding [...] has been confirmed by many other studies of professional programmers (Curtis 1981, Mills 1983, DeMarco and Lister 1985, Curtis et al. 1986, Card 1987, Boehm and Papaccio 1988, Valett and McGarry 1989, Boehm et al 2000).

Rien ne fait plus "scientifique" que cette litanie de citations. Mais qu'en est-il en regardant de plus près?

• L'étude de Curtis de 1981 porte sur 60 programmeurs confrontés à nouveau à une tâche de mise au point et non de programmation.
• L'article de Curtis de 1984 n'est pas une étude, mais un appel à mieux intégrer les sciences cognitives dans le génie logiciel. (Au demeurant je rejoins Curtis à ce sujet, mais j'y reviendrai.) 
• La citation de Mills 1983 se réfère à un livre regroupant divers essais sur la productivité, essentiellement des retours d'expérience et articles d'opinion, mais aucun qui porte sur une réplication de l'étude originelle.
• De même pour DeMarco et Lister 1985, il s'agit du célèbre "Peopleware", pavé jeté dans la mare d'une certaine forme de management par la presssion malheureusement toujours en vogue de nos jours; les seules "études" relatées portent sur des compétitions de programmation organisées par les auteurs, dans des conditions peu contrôlées (les participants devaient réaliser les exercises proposés sur leur lieu de travail et pendant les heures de bureau).
• La référence Card 1987 n'est pas une publication scientifique mais le rapport d'activité d'un laboratoire privé, où apparaissent quelques tableaux de synthèse dont aucun ne semble directement confirmer "des écarts de productivité de 1 à 10"
• La référence Boehm et Papaccio 1988 est un travail de synthèse qui cite plusieurs autres publications, la seule qui soit citée sur les variations de productivité étant... l'étude de 1968!
• Je n'ai pas pu vérifier la référence Boehm 2000 (de toutes façons, un livre sur COCOMO et non une publication scientifique)
• Une seule de ces références reproduit réellement le résultat d'origine mais indirectement, c'est Valett 1989, rapportant une étude de 1982 qui mesure la productivité en nombre de lignes de code (une approche fortement critiquée depuis) et fait apparaître des disparités dans un rapport de 1 à 8 sur de "petits" projets (moins de 20K lignes) et dans un rapport de 1 à 20 sur les gros projets. Comme il s'agit d'une citation d'une citation, presque aucun détail sur la méthode de collecte de données n'est disponible.

Dans l'ensemble le tableau n'est guère encourageant: McConnell détourne le mécanisme de la citation scientifique et ne cherche qu'à donner de l'autorité à un énoncé qui ne la tient que d'une ou deux études préliminaires. (Je n'ai pas fait le travail critique équivalent quant aux recherches citées par McConnell sur les variations de productivité entre équipes. Malheureusement, un travail critique prend beaucoup plus de temps qu'il n'en faut pour émettre des assertions mal étayées, une asymétrie qui explique peut-être l'état de nos connaissances dans certains domaines.)

Pourquoi reste-t-on dans le folklore?


Pour moi le verdict est clair, la prétendue observation "scientifique" sur l'ordre de grandeur des variations de productivité individuelle relève du folklore, des éléments d'opinion non confirmés qui se transmettent et se perpétuent pour des raisons plus culturelles que rationelles. (Je ne prétends pas qu'il n'y a pas de variations de productivité de cet ordre: je dis simplement que ce "fait" n'est pas démontré, et qu'on ne sait pas quoi en faire.)

L'une des raisons à cela est qu'on n'est pas en mesure de cerner avec assez de précision la notion de "productivité". A l'origine, on avait tendance à mesurer en lignes de code. Avec le développement de "langages de haut niveau" on a sévèrement remis en cause cette mesure de productivité, puisqu'ils permettaient précisément de faire la même chose en moins de lignes. On a tenté de leur substituer les points de fonction, qui s'avèrent compliqués et peu utilisés par la profession. Mais la vraie question à poser est celles des hypothèses qui sous-tendent la notion de "productivité".

Par exemple, considérons-nous qu'une productivité ne peut être que positive ou nulle? C'est une hypothèse battue en brèche par la notion de "net negative productivity programmers": des membres d'une équipe qui non seulement n'apportent pas une contribution à la productivité mais détruisent celle des autres intervenants.

Faisons-nous la différence entre les efforts et les résultats? Un programmeur peut très bien sembler improductif parce qu'il fournit peu de travail, mais s'il est à l'origine d'une idée innovante qui permet de ne pas coder plusieurs fonctionnalités complexes, sa contribution est d'une grande valeur.

Une notion importante dans les sciences sociales et cognitives est celle de "construct validity", c'est à dire de répondre à la question: ce que nous mesurons a-t-il une existence réelle, et est-il réellement reflété dans les mesures avec lesquelles nous avons choisi de l'opérationnaliser? (Consultez par exemple l'article sur la psychométrie de Wikipedia.) Ces questions semblent peu posées dans notre domaine; sans doute parce que nous ne nous inspirons pas des bonnes disciplines, et je reviendrai sur ce point prochainement.

Sortir du folklore

Au fil de la construction du référentiel des pratiques Agiles, le recensement des études empiriques pertinentes et, par le jeu des citations, les faits établis ou en construction dont elles dépendent permettra, c'est en tout cas mon intention, de définir les contours de ce que nous savons et de ce que nous ne savons pas encore sur le sujet.

Ce travail ne s'arrête pas au référentiel: il est important aussi de recenser qui travaille sur ces sujets, en France notamment mais ailleurs également, et mettre en lumière les collaborations (pour l'instant encore trop rares) visant à rapprocher la communauté Agile et le milieu de la recherche. A plus long terme, l'Institut Agile cherchera à initier, ou en tout cas à apporter une contribution, à un espace permettant aux chercheurs de publier plus efficacement.