Prochain Rendez-Vous de l'Institut: le 22 mars à Caen

L'Institut sort de Paris pour son prochain Rendez-Vous:"Vous avez dit Management Agile ?"

Il s'agit d'une journée pleine, proposée par l'Institut Agile, le Chapitre France-Atlantic du PMI et l'Université de Caen, qui se tiendra le 22 mars 2012 à Caen. Vous pouvez télécharger la plaquette ou vous inscrire sur le site du Chapitre.

Naissance d'une communauté: Enseigner Agile

Le 9 novembre s'est réuni une nouvelle communauté thématique à l'initiative de l'Institut Agile: elle se composait d'enseignants en activité et d'intervenants issus de l'industrie. (Plusieurs d'entre nous ont d'ailleurs eu des parcours mixtes: ex-enseignants devenus ingénieurs ou chefs de projet, ex-ingénieurs devenus enseignants, par exemple.) Une dizaine de personnes étaient présentes.

Enseignement Agile: le 9 novembre à l'Epitech

Les inscriptions sont ouvertes pour le prochain Rendez-Vous de l'Institut Agile, consacré comme évoqué précédemment à la place et au rôle des pratiques Agiles dans l'enseignement supérieur.

Peut-on, doit-on enseigner les approches Agiles au sein des universités et écoles d'ingénieur? Si oui, comment?

C'est à ces questions que nous vous invitons à répondre lors d'une soirée-débat gratuite, qui fera suite à la rencontre inaugurale d'un nouveau réseau national d'enseignants et intervenants ayant intégré les pratiques Agiles au sein de leurs contenus pédagogiques. Nous serons accueillis par l'Epitech à Paris.

Etymologie d'un terme Agile: le backlog

Si vous êtes agiliste, vous connaissez le mot "backlog", mais vous êtes-vous interrogé sur ses origines et ses connotations?

Agile et en forme!

Un des inconvénients de nos métiers est sans doute le temps que nous passons assis: apparemment, ce n'est pas très bon pour la santé.

Heureusement pour les équipes agiles, on se lève au moins une fois par jour... Ce n'est sans doute pas suffisant. Sans aller jusqu'à remplacer votre bureau par un tapis de marche comme certains de nos collègues, vous avez peut-être, pour y remédier, inclus un peu de jogging dans vos activités régulières.

Les Rendez-Vous de l'Institut: Enseignement Agile

Parmi les sujets que l'Institut Agile entend traiter en priorité, on trouve en bonne place la recherche et l'enseignement.

Que pouvons-nous apprendre, par la méthode expériementale notamment, sur les pratiques Agiles et leur relation à d'autres "bonnes pratiques"dans le domaine du logiciel? Mais également, et les deux sujets sont indissociables, comment favoriser l'acquisition de ces connaissances (et d'autres) par les élèves, les étudiants et les jeunes diplômés d'aujourdhui qui vont (rapidement) devenir les professionnels du logiciel de demain? C'est un enjeu d'avenir mais encore peu abordé par la communauté Agile.

Premier Rendez-vous de l'Institut Agile: 04/05

Le 4 mai, l'Institut Agile vous invite au premier de ses Rendez-Vous. (Attention: changement de date par rapport à la première annonce!)

Petit à petit le projet de l'Institut Agile se construit, grâce au soutien de ses partenaires. Comme annoncé au fil de ce blog divers livrables importants ont vu le jour: le référentiel des pratiques agiles, les premières sessions "Master Class", les premières communautés thématiques. D'autres projets encore en couveuse produiront prochainement leurs résultats.

Première communauté thématique de l'Institut Agile: Contrats Agiles

La première réunion de groupe de travail "Contrats Agiles" de l'Institut s'est tenue le 17 janvier dernier; ce billet en donne un compte-rendu. (Pour en savoir plus, vous pouvez également participer à la liste de diffusion "Institut Agile - Contrats")

Session "Innovation Games" les 29 et 30 mars 2011, première Master Class

Ouverture des inscriptions

Les inscriptions sont ouvertes dès aujourd'hui pour la première Master Class de l'Institut Agile.

Celle-ci a pour thème les Innovation Games popularisés par Luke Hohmann. Elle se déroulera les 29 et 30 mars à Paris et sera animée en anglais par Maarten Volders, instructeur accrédité par Innovation Games Inc.

On "fact and folklore"

Late in 2010 I published on the blog of Institut Agile an essay in French, the latter half of which was a critique of Steve McConnell's 2008 blog entry "Productivity Variations Among Developers and Teams: The Origin of 10x". The context of this critical essay was a series in which I examined some of the issues in arriving at reliable knowledge in the domain of software engineering.

In January, I posted to my personal GitHub site and to various social networks an English translation of that article, which thanks to the leverage of social networks enjoyed a relatively wide audience. This led to a series of exchanges on the blog of Steve McConnell and others, and some private correspondence. On net, my impression has been that this discussion has left the topic no clearer than it was previously, and I take responsibility for this poor result.

On reflection I have come to realize that my claims, in both the original and the translated version, that McConnell was "cheating with citations" and "abusing the mechanism of scientific citation" were overblown. As a consequence of this carelessness on my part, the discussions that ensued were less fruitful than they might have been if I had presented my findings in a more neutral way, to be improved upon as necessary in the interests of factual accuracy.

Even when dealing with charged issues, my normal mode of operation in debate is to avoid framing it as one person against another, but as both working in pursuit of some truth; in this instance, and on several occasions over a period of time, I did less than my best.

On the bright side, I'm happy with many of the insights I was able to glean from this exchange, frustrating as it may have been to other readers. I am resolved to do a better job, at some future time, of presenting what I found during my investigation of the empirical evidence that McConnell and others have collected regarding programmer productivity. (A draft of this report is available and I will provide it upon request.)

Traduction de "folklore ou fait scientifique"

Hier, j'ai pris le temps, suite à diverses conversations avec des confrères anglophones, de traduire ce billet, sous le titre "Fact and folklore in software engineering".

Grâce au relais de HackerNews et de Twitter, l'article a été lu 12000 fois entre sa parution hier et le présent billet, soit moins de 24h. (Andy Warhol avait raison.)

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.