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.)
Affichage des articles dont le libellé est productivité. Afficher tous les articles
Affichage des articles dont le libellé est productivité. Afficher tous les articles
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:
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.
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.
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.
De l'opinion au savoir
Dans mon billet précédent je pointais ce qui me semble être des faiblesses des études actuellement les plus diffusées sur les "bénéfices de l'Agilité".
Pour ceux qui ont suivi les épisodes précédents, ce n'est pas difficile de comprendre d'où me vient cette attitude critique: d'une part parler "d'un projet Agile" en soi ne veut pas dire grand-chose, puisque ça ne nous dit rien sur ce que font les gens; d'autre part les apparences de la science ne suffisent pas à faire d'une étude quelque chose qui créée de la connaissance: le Culte du Cargo existe aussi dans le domaine scientifique.
J'ai entendu plus d'une fois l'argument suivant:
Qu'est-ce que c'est, sans vouloir chercher midi à quatorze heures, qu'un savoir scientifique? C'est un énoncé qui se vérifie de manière fiable dans toute une catégorie de situations, indépendamment des opinions de l'observateur. Par exemple "l'eau bout à 100 degrés" est une observation qui se vérifie avec beaucoup de régularité, et en particulier indépendamment de mes convictions sur ce que l'eau devrait faire à telle ou telle température, de mes décrets ou de mes incantations à ce sujet.
Certes il existe des exceptions: par exemple, si on veut faire du bon café au sommet de l'Himalaya, il vaut mieux savoir que la pression atmosphérique joue un rôle dans cette relation fiable entre l'état liquide ou gazeux de l'eau et sa température. Pour être vraiment précis, on pourra dire "l'eau bout à 100 degrés dans les conditions normales de pression et de température ambiante." Ces exceptions ne sont pas plus une affaire d'opinion que la règle à laquelle elles s'opposent. Le point d'ébullition de l'eau est un fait réel; pour reprendre une citation de Philip K. Dick: "la réalité, c'est ce qui continue d'exister même si vous cessez d'y croire".
A quelles réalités sommes-nous confrontés dans le domaine du logiciel? Elles sont de deux catégories, et malheureusement les recherches scientifiques à ce sujet ont tendance à faire, au mieux une impasse, au pire de graves contre-sens, vis-à-vis de l'une de ces catégories.
D'une part il existe la réalité de ce qu'un programme peut ou ne peut pas faire. Cette branche, c'est (dans les grandes lignes) l'algorithmique, la discipline appelée imprudemment "computer science", étrange étiquette puisqu'elle s'apparente plus aux mathématiques qu'aux sciences expérimentales et qu'elle n'étudie quasiment pas les ordinateurs. Les faits qu'on y découvre sont souvent très contre-intuitifs et leur applicabilité pratique rarement évidente. Par exemple la Thèse de Church-Turing qui permet notamment de démontrer que tous les langages de programmation et tous les ordinateurs se valent, du moins en termes de leur capacité à instantier n'importe quel processus qui peut s'exprimer sous la forme d'un programme: dans la pratique, les programmeurs professionnels sont précisément intéressés par l'inverse de cette conclusion, à savoir quel langage est le plus approprié.
La raison tient à l'autre catégorie de réalités pertinentes dans le domaine du logiciel: celles qui concernent le fonctionnement et les limitations de l'esprit humain. Nous ne nous intéressons que de loin en loin à ce qu'il est possible "en principe" à un ordinateur de faire; au quotidien, nous sommes plus concernés par leur application "en pratique", et notamment à savoir à quel coût et en combien de temps nous pouvons faire quelque chose, et quels sont les facteurs qui influent sur ces réponses.
Est-ce qu'il est impossible d'étudier le fonctionnement et les limitations de l'esprit humain? Pas du tout, la psychologie et les sciences cognitives le font depuis fort longtemps. Pour autant, il faut avancer avec prudence, parce que dès lors qu'on s'intéresse à l'humain, les opinions et croyances de l'observateur ou de l'observé ont une fâcheuse tendance à influer sur les résultats des expériences! On connait par exemple les distortions introduites par l'effet placebo, qu'on va chercher à éliminer par la mise en place de protocoles expérimentaux adaptés, tels que les protocoles en double aveugle.
L'équivalent dans notre domaine de l'effet placebo pourrait bien être l'effet Hawhthorne: lorsque des travailleurs savent qu'ils sont les sujets d'une expérience sur les conditions de travail, leur performance s'améliore, indépendamment des conditions expérimentales précises auxquelles ils sont soumis. Ce résultat souligne au passage que la motivation est un paramètre expérimental comme un autre, une observation qui a son importance. Elle peut facilement menacer la validité d'une étude scientifique sur la performance ou la productivité.
Contrairement à ce qu'on peut découvrir sur le point d'ébullition de l'eau, ces études ont aussi en commun avec, par exemple, la recherche médicale le fait de s'intéresser à des phénomènes qui sont rarement systématiques, mais au contraire présentent un aspect probabiliste. Cette difficulté vient de ce que l'esprit humain est complexe, il se compose d'un très grand nombre de processus qui contribuent de façon différente et parfois contradictoire aux résultats observés (et peuvent même interagir). Selon le processus qui l'emporte dans une situation donnée, le résultat peut être différent; il n'est généralement pas possible de reproduire la situation initiale avec assez de fidélité pour obtenir systématiquement le même résultat.
Est-il impossible d'étudier scientifiquement des phénomènes résultant, de façon probabiliste, de processus complexes? Evidemment pas; il faut par contre se doter des outils appropriés. La statistique permet de décrire les relations entre les paramètres qu'on arrive à tenir fixe d'une situation à une autre, et les résultats observés. Elle permet par exemple de mettre en évidence des corrélations, qui sont la matière première principale de très nombreuses études. Là aussi, il faut savoir rester prudent. Ce n'est pas l'outil statistique en soi qui rend scientifique une étude. Il faut savoir se méfier, par exemple, des conclusions hâtives à la lecture de simples corrélations.
Saviez-vous par exemple qu'une étude scientifique a constaté, sur un échantillon représentatif de plages touristiques, qu'il existait une nette corrélation entre le nombre de sorbets et crèmes glacées vendues par les buvettes chaque saison et le nombre de morts par noyade? On pourrait être tenté d'appeler au vote d'une loi interdisant la vente de glaces... Ce qui serait une idiotie: ce sont en fait deux paramètres corrélés à un troisième, la fréquentation des plages. S'il fait beau et chaud et qu'il vient beaucoup de monde sur la plage, on vendra plus de glaces ET il y aura (statistiquement, c'est hélas difficile à éviter) plus de noyades. Cette erreur est désignée de plusieurs façons: "cum hoc ergo propter hoc", "corrélation n'est pas causation", etc.
Raisonner de façon claire sur les phénomènes probabilistes n'est pas chose simple, parce que l'esprit humain est mal équipé pour traiter les probabilités. Je reviendrai là-dessus plus tard, lorsque j'aborderai un sujet presque totalement ignoré dans la recherche sur le génie logiciel, qui joue pourtant un rôle majeur pour expliquer la presque totalité des difficultés que nous rencontrons encore quarante ans après le "constat de crise" de notre profession: celui des biais cognitifs.
Il me semble parfaitement possible d'étudier de façon scientifique une question telle que "les approches Agiles ont-elles plus d'intérêt", mais il est clair que pour le faire il n'est pas possible de s'arrêter à une interprétation naïve de cette question. Il faut regarder de plus près, d'une part ce qu'on veut dire par une approche Agile, mais aussi ce qu'est le travail des scientifiques.
Dans le prochain billet, je reviendrai sur un exemple très concret pour illustrer un élément important de ce travail: le "fait scientifique" selon lequel la productivité des programmeurs varie dans un rapport de 1 à 20.
Pour ceux qui ont suivi les épisodes précédents, ce n'est pas difficile de comprendre d'où me vient cette attitude critique: d'une part parler "d'un projet Agile" en soi ne veut pas dire grand-chose, puisque ça ne nous dit rien sur ce que font les gens; d'autre part les apparences de la science ne suffisent pas à faire d'une étude quelque chose qui créée de la connaissance: le Culte du Cargo existe aussi dans le domaine scientifique.
J'ai entendu plus d'une fois l'argument suivant:
Ce n'est pas possible d'aborder de façon scientifique les projets logiciels, parce qu'ils sont le fait d'individus, humains et uniques, et que leurs projets sont eux-mêmes uniques.Je ne suis absolument pas d'accord.
Qu'est-ce que c'est, sans vouloir chercher midi à quatorze heures, qu'un savoir scientifique? C'est un énoncé qui se vérifie de manière fiable dans toute une catégorie de situations, indépendamment des opinions de l'observateur. Par exemple "l'eau bout à 100 degrés" est une observation qui se vérifie avec beaucoup de régularité, et en particulier indépendamment de mes convictions sur ce que l'eau devrait faire à telle ou telle température, de mes décrets ou de mes incantations à ce sujet.
Certes il existe des exceptions: par exemple, si on veut faire du bon café au sommet de l'Himalaya, il vaut mieux savoir que la pression atmosphérique joue un rôle dans cette relation fiable entre l'état liquide ou gazeux de l'eau et sa température. Pour être vraiment précis, on pourra dire "l'eau bout à 100 degrés dans les conditions normales de pression et de température ambiante." Ces exceptions ne sont pas plus une affaire d'opinion que la règle à laquelle elles s'opposent. Le point d'ébullition de l'eau est un fait réel; pour reprendre une citation de Philip K. Dick: "la réalité, c'est ce qui continue d'exister même si vous cessez d'y croire".
A quelles réalités sommes-nous confrontés dans le domaine du logiciel? Elles sont de deux catégories, et malheureusement les recherches scientifiques à ce sujet ont tendance à faire, au mieux une impasse, au pire de graves contre-sens, vis-à-vis de l'une de ces catégories.
D'une part il existe la réalité de ce qu'un programme peut ou ne peut pas faire. Cette branche, c'est (dans les grandes lignes) l'algorithmique, la discipline appelée imprudemment "computer science", étrange étiquette puisqu'elle s'apparente plus aux mathématiques qu'aux sciences expérimentales et qu'elle n'étudie quasiment pas les ordinateurs. Les faits qu'on y découvre sont souvent très contre-intuitifs et leur applicabilité pratique rarement évidente. Par exemple la Thèse de Church-Turing qui permet notamment de démontrer que tous les langages de programmation et tous les ordinateurs se valent, du moins en termes de leur capacité à instantier n'importe quel processus qui peut s'exprimer sous la forme d'un programme: dans la pratique, les programmeurs professionnels sont précisément intéressés par l'inverse de cette conclusion, à savoir quel langage est le plus approprié.
La raison tient à l'autre catégorie de réalités pertinentes dans le domaine du logiciel: celles qui concernent le fonctionnement et les limitations de l'esprit humain. Nous ne nous intéressons que de loin en loin à ce qu'il est possible "en principe" à un ordinateur de faire; au quotidien, nous sommes plus concernés par leur application "en pratique", et notamment à savoir à quel coût et en combien de temps nous pouvons faire quelque chose, et quels sont les facteurs qui influent sur ces réponses.
Est-ce qu'il est impossible d'étudier le fonctionnement et les limitations de l'esprit humain? Pas du tout, la psychologie et les sciences cognitives le font depuis fort longtemps. Pour autant, il faut avancer avec prudence, parce que dès lors qu'on s'intéresse à l'humain, les opinions et croyances de l'observateur ou de l'observé ont une fâcheuse tendance à influer sur les résultats des expériences! On connait par exemple les distortions introduites par l'effet placebo, qu'on va chercher à éliminer par la mise en place de protocoles expérimentaux adaptés, tels que les protocoles en double aveugle.
L'équivalent dans notre domaine de l'effet placebo pourrait bien être l'effet Hawhthorne: lorsque des travailleurs savent qu'ils sont les sujets d'une expérience sur les conditions de travail, leur performance s'améliore, indépendamment des conditions expérimentales précises auxquelles ils sont soumis. Ce résultat souligne au passage que la motivation est un paramètre expérimental comme un autre, une observation qui a son importance. Elle peut facilement menacer la validité d'une étude scientifique sur la performance ou la productivité.
Contrairement à ce qu'on peut découvrir sur le point d'ébullition de l'eau, ces études ont aussi en commun avec, par exemple, la recherche médicale le fait de s'intéresser à des phénomènes qui sont rarement systématiques, mais au contraire présentent un aspect probabiliste. Cette difficulté vient de ce que l'esprit humain est complexe, il se compose d'un très grand nombre de processus qui contribuent de façon différente et parfois contradictoire aux résultats observés (et peuvent même interagir). Selon le processus qui l'emporte dans une situation donnée, le résultat peut être différent; il n'est généralement pas possible de reproduire la situation initiale avec assez de fidélité pour obtenir systématiquement le même résultat.
Est-il impossible d'étudier scientifiquement des phénomènes résultant, de façon probabiliste, de processus complexes? Evidemment pas; il faut par contre se doter des outils appropriés. La statistique permet de décrire les relations entre les paramètres qu'on arrive à tenir fixe d'une situation à une autre, et les résultats observés. Elle permet par exemple de mettre en évidence des corrélations, qui sont la matière première principale de très nombreuses études. Là aussi, il faut savoir rester prudent. Ce n'est pas l'outil statistique en soi qui rend scientifique une étude. Il faut savoir se méfier, par exemple, des conclusions hâtives à la lecture de simples corrélations.
Saviez-vous par exemple qu'une étude scientifique a constaté, sur un échantillon représentatif de plages touristiques, qu'il existait une nette corrélation entre le nombre de sorbets et crèmes glacées vendues par les buvettes chaque saison et le nombre de morts par noyade? On pourrait être tenté d'appeler au vote d'une loi interdisant la vente de glaces... Ce qui serait une idiotie: ce sont en fait deux paramètres corrélés à un troisième, la fréquentation des plages. S'il fait beau et chaud et qu'il vient beaucoup de monde sur la plage, on vendra plus de glaces ET il y aura (statistiquement, c'est hélas difficile à éviter) plus de noyades. Cette erreur est désignée de plusieurs façons: "cum hoc ergo propter hoc", "corrélation n'est pas causation", etc.
Raisonner de façon claire sur les phénomènes probabilistes n'est pas chose simple, parce que l'esprit humain est mal équipé pour traiter les probabilités. Je reviendrai là-dessus plus tard, lorsque j'aborderai un sujet presque totalement ignoré dans la recherche sur le génie logiciel, qui joue pourtant un rôle majeur pour expliquer la presque totalité des difficultés que nous rencontrons encore quarante ans après le "constat de crise" de notre profession: celui des biais cognitifs.
Il me semble parfaitement possible d'étudier de façon scientifique une question telle que "les approches Agiles ont-elles plus d'intérêt", mais il est clair que pour le faire il n'est pas possible de s'arrêter à une interprétation naïve de cette question. Il faut regarder de plus près, d'une part ce qu'on veut dire par une approche Agile, mais aussi ce qu'est le travail des scientifiques.
Dans le prochain billet, je reviendrai sur un exemple très concret pour illustrer un élément important de ce travail: le "fait scientifique" selon lequel la productivité des programmeurs varie dans un rapport de 1 à 20.
Inscription à :
Articles (Atom)
Articles
