[NewCrafts 2017] Perpetual infancy – Why software doesn’t seem to be growing up

« Those who do not remember history are doomed to repeat it. »
— Santayana

À l’occasion de la conférence NewCrafts 2017, Laurent Bossavit nous propose un talk sur l’Histoire de l’informatique avec un grand H, et sur l’évolution de ses pratiques à travers le XXème siècle. Plus précisément, il constate que notre industrie a tendance à oublier sa propre histoire, et se demande comment y remédier.

Le développement logiciel en tant que profession anhistorique

Nous vivons immergés depuis toujours dans des termes qui nous paraissent très familier : informatique et l’ingénierie logicielle. Mais depuis quand ces expressions existent-elles ? Google Ngram Viewer permet de rechercher la fréquence d’apparition de n’importe quel terme parmi le corpus Google Books. En voici les résultats :

« Computer science » est devenu populaire dans la littérature un peu avant 1965. « Software engineering », environ 10 ans plus tard, pendant les années 1970.

L’acte fondateur du concept de génie logiciel a été la conférence de l’OTAN de 1968, une conférence de travail centrée sur la « crise du logiciel » et les difficultés que l’industrie rencontrait à l’époque pour produire des logiciels. Avant cette date, l’idée d’associer les deux mots « logiciel » et « ingénierie » faisait presque controverse. Pourtant, la majorité des difficultés auxquelles nous faisons face aujourd’hui était déjà présente en 1968.

« It therefore seems natural that we should turn to architects for ideas about how to attack the design problem. »
— Peter Naur

Malheureusement, cet événement est très peu enseigné dans nos écoles et universités, tout comme le reste de l’histoire de l’informatique. Pire, on peut s’étonner du très faible nombre de musées dédiés à notre profession. Il existe bien le « Computer History Museum » à la Silicon Valley, mais la France n’en compte aucun (La Défense hébergeait un « musée de l’informatique » en 2008 qui n’est resté ouvert que deux ans.)

Nous ne connaissons pas notre histoire, et c’est certainement un facteur qui explique une certaine frustration que l’on peut ressentir dans notre métier.

Pourquoi c’est un problème

Nous sommes maintenant en 2017 et malgré cela, les grands projets informatiques continuent à échouer, les développeurs continuent d’apprendre de « nouvelles » technologies à intervalle de temps régulier, et nos IDE peuvent consommer jusqu’à 13% de CPU pour afficher un curseur qui clignote.

Tout le monde a déjà vu ce dessin humoristique qui se moque du métier de programmeur :

En cherchant la source du dessin, on trouve une plus ancienne version qui date des années 1970 :

Dans cette version, le dessin se moque tout simplement des difficultés de communiquer dans une entreprise et au sein de ses différents départements. La source originelle n’a jamais été trouvée, mais elle pourrait remonter à la première moitié du XXème siècle.

Cet exemple illustre le problème de l’industrie du développement logiciel qui vit dans un cycle perpétuel de redécouvertes. On peut citer l’exemple des conteneurs, terme en vogue depuis quelques années mais dont une implémentation existait déjà 1979 avec chroot. Ou bien les langages orientés objet modernes Java/C#, inspirés fortement de Smalltalk (1971). Plus significatif encore, l’engouement actuel pour la programmation fonctionnelle qui était déjà utilisée dans les années 1950 avec Lisp.

Si nous connaissions mieux l’histoire de ces technologies, pourquoi elles ont été conçues et comment elles ont été utilisées, nous serions plus méfiants vis-à-vis des « silver bullets », ces outils et frameworks qui promettent de résoudre tous nos problèmes et d’avoir une productivité hors norme !

Ce qui nous ramène à la citation du philosophe George Santayana citée au début de cet article, un peu plus complexe dans sa version complète :

« Progress, far from consisting in change, depends on retentiveness [ce que l’on retient, ndlr]. When change is absolute there remains no being to improve and no direction is set for possible improvement: and when experience is not retained, as among savages, infancy is perpetual. Those who cannot remember the past are condemned to repeat it. »
— George Santayana

Ce que veut dire Santayana ici est que, si l’on se contente de changer sans jamais retenir ce que l’on a fait précédemment, alors on ne peut pas s’améliorer. « L’enfance » dont il parle est la période où l’on expérimente sans vraiment apprendre, où l’on est sans-cesse étonné mais aussi distrait par le monde. Le progrès est donc difficile et ne viendra qu’avec une certaine maturité. Cette maturité nous rend capable d’analyser et de retenir de nos expériences.

Comment être un (mauvais) historien

Laurent Bossavit a travaillé pour l’Agile Alliance à préserver et à archiver les comptes-rendus des conférences de la communauté Agile qui se sont tenues entre 2002 et 2012. Il a également produit le document suivant, la « carte de métro des pratiques agiles », montrant les interconnexions des pratiques venant de différentes communautés (Scrum, XP, DevOps, etc.) :

Dans le cadre de ses recherches historiques, Laurent s’est intéressé à des concepts plus généraux du génie logiciel comme la notion du coût des erreurs (« cost of defects ») qui est présentée sur le schéma ci-dessous. L’idée est que, plus la découverte d’un bug est éloignée du moment où il est créé, plus sa correction sera complexe et coûteuse. Par exemple, une erreur ou un oubli dans les spécifications fonctionnelles sera difficile à adresser s’il n’est remarqué qu’après la mise en production de la solution.

Cette conclusion sert généralement à justifier l’usage du Test Driven Development car celui-ci nous aide à valider au plus tôt le code que l’on produit.

En se penchant sur le sujet, on se rend compte que ce phénomène du coût croissant des erreurs était déjà connu dans les années 1980. Mais à l’époque, la conséquence avait été de dire que, si les erreurs les plus graves d’un projet apparaissent pendant la conception, alors nous devrions mettre plus d’effort sur la phase de spécification au début du projet. Et d’encourager ainsi les méthodologies du type Cycle en V ou Cascade. Vingt ans plus tard, les mêmes données seront réutilisées pour promouvoir les pratiques de développement incrémental et de tests automatisés.

Puis, en creusant un peu plus loin, on peut retrouver les données originelles de cette étude des années 1980 :

Les courbes du bas montrent le temps passé à corriger des bugs à partir du début du projet et les courbes du haut, le temps total passé à développer. On s’aperçoit que, malgré des variations, les deux courbes restent relativement proportionnelles l’une à l’autre. Cela semblerait contredire la croyance que le temps de correction augmente exponentiellement avec le temps. Et en effet, il n’existe aucune étude scientifique qui apporte cette conclusion.

 

« History is a story about the past that is significant and true. »

Le métier de l’historien est d’étudier les sources primaires de l’époque, c’est-à-dire les textes et artefacts créés à ce moment. Dans le cas de l’informatique, les artefacts sont constitués des programmes en eux-mêmes, des articles de l’époque, de la documentation produite, etc. A partir des sources les plus représentatives et les plus significatives, l’historien développe des hypothèses et des interprétations, appelées sources secondaires.

Mais ces interprétations sont bien souvent elles-mêmes basées sur d’autres sources secondaires. De fil en aiguilles, les faits sont déformés et faussent notre perception des événements. Encore plus dangereux, certains historiens peuvent avoir tendance à biaiser leurs analyses pour orienter le lecteur vers une certaine interprétation et mettre en avant leurs convictions.

La conférence de l’OTAN de 1968 est généralement décrite comme la conséquence de la « crise du logiciel », un concept imaginé par Dijkstra pour expliquer la difficulté croissante de l’industrie à mener à terme les projets informatiques. Selon l’historien Thomas Haigh, la motivation cachée de Dijkstra était d’obtenir des financements pour la création d’un institut de l’ingénierie logicielle.

Reprendre possession de notre histoire

Nous avons conservé nos logiciels, leurs codes sources, les ordinateurs et d’autres technologies, mais nous n’avons que très peu de trace de l’informatique en tant qu’activité humaine. Et nous avons donc oublié les réflexions qu’ont eu nos prédécesseurs, les erreurs qu’ils ont commises ou encore les pratiques qu’ils ont expérimentés.

Pour remédier à cela, Laurent Bossavit nous propose quelques conseils de lecture : « The Computer Boys Take Over » est un livre qui reprend l’histoire des hommes et des femmes derrière la révolution informatique du milieu du XXème siècle (où les femmes était d’ailleurs bien mieux représentées qu’aujourd’hui). Il a également créé une liste collaborative de lecture sur GitHub : http://bit.ly/craft-history.

Laurent est convaincu que, par l’étude et par la compréhension de notre histoire, nous serons capables de surmonter les principales difficultés de notre industrie, que ce soit les projets en échec, le sentiment désagréable de réinventer régulièrement la roue ou plus généralement, la fracture culturelle entre les jeunes et les anciens programmeurs.

 

 

Pas de commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *