Doit-on montrer le code informatique des scientifiques même s'il est moche ?

[caption id="attachment_631" align="aligncenter" width="103"] cliquez sur l'image (puis laissez la souris au-dessus de l'image pour voir le texte alternatif) (et si vous riez, vous êtes un affreux geek)[/caption]

En science on écrit beaucoup de code informatique. On écrit de gros programmes pour traiter plein de données (génomique, résultats du CERN), d'autres gros programmes pour simuler de gros modèles pour quand la réalité est complexe (le climat, les populations humaines), encore des gros programmes pour traiter des données compliquées (des structures cristallographiques). Et on écrit des petits programmes tout le temps : pour lier les gros entre eux, pour mettre les données au bon format, pour faire un petit calcul pas standard dans le logiciel, pour répéter une opération simple plein de fois, etc. (Je précise qu'il existe aussi des scientifiques qui ne programment pas. Il n'est pas question d'eux aujourd'hui.)

Au bilan, la qualité et la fiabilité de nos résultats scientifiques dépendent pas mal de tout ce code.

Et qu'est qu'on en fait, le plus souvent ? On l'écrit vite et mal, on le teste à peine, on ne le commente pas, et on le paume quelque part dans un sous-dossier de notre disque dur. La honte.

Une excellente analogie que j'ai trouvée récemment (document PDF) : peut-on imaginer que les mathématiciens publient leurs théorèmes sans montrer les preuves, parce que c'est du boulot de les mettre en forme, parce que chaque preuve est particulière à un problème et pas très utile ailleurs, c'est plus rentable de travailler sur un nouveau problème que de polir cette preuve pour publication, en fait ma preuve ne marche pas dans tous les cas mais dans le cas qui m'intéresse ça marchait, en fait c'est mon étudiant qui a fait la preuve et je ne l'ai plus, la preuve va me re-servir pour d'autres théorèmes alors je ne vais pas la donner à mes compétiteurs, les papiers avec des preuves seraient trop longs et les experts ne vont pas s'embéter à lire tout ça, ma preuve s'appuie sur un logiciel commercial (genre MatLab), vous pourrez pas vous en servir, etc.

Pour de vrai, les mathématicens publient leurs preuves, mais les scientifiques ne publient pas leur (notre) code, et nos arguments sont à-peu-près ceux ci-dessus.

Le point qui fait le plus débat est le compromis entre le travail nécessaire à rendre son code informatique présentable, et la pertinence de publier du code "sale". Ca fait longtemps que j'ai ce billet en brouillon et je veux le publier et je ne vais pas réussir à écrire tout ce que je voudrais, alors je vais mettre quelques liens intéressants avec des résumés :

• Iddo Friedberg a fait un excellent bilan sur son blog Byte Size Biology, avec une analogie très drôle au film "Piranha 3D", et conclut qu'en l'état il n'a pas les moyens de faire du code propre, et ne veut pas partager du code pas propre, mais propose une nouvelle initiative, le Bioinformatic Testing Consortium,


• Dans Nature, un article Publish your computer code: it is good enough argue que même si le code n'est pas beau ni propre ni aux règles, il faut le publier, ça fait partie de la démarche scientifique.


• Un autre article dans Nature, Computational science: ...Error, prends plus ou moins l'angle inverse, et dit qu'il faut former tous les scientifiques au génie logiciel propre.


• Un blog anonyme réagit à Iddo en disant que le but de la science n'est pas des logiciels, et donc des tests systématiques ne sont pas justifiés.


• Un autre bloguer, Titus Brown, donne de bonnes raisons pour écrire du code proprement en respectant les règles, et donne de bons conseils pour le faire efficacement. Super citation de Darwin :
  

  "Ignorance more frequently begets confidence than does knowledge"

  
  


• Sur le forum Biostar, un bioinformaticien anonyme dit que de documenter et publier son code est du même ordre de grandeur que de noter ses procédures expérimentales : indispensable. (LOLcat si vous suivez le lien)


• John Graham-Cumming note que le problème se pose avec encore plus de force dans l'étude du climat, où l'obscurité des méthodes devient un argument politique.

Un gros problème est qu'en science on doit souvent écrire du code pour des projets qui se développent au fur et à mesure, sans savoir où on sera demain, et quel bout de code finira inutile et lequel produira le résultat critique pour la suite, voire lequel servira de base à une nouvelle méthode utilisée par ses collègues. Le fait est que dans la plupart des cas le code est vite fait - mal fait.

Il s'ajoute un autre problème : on a beau vous expliquer que si vous programmez proprement vous gagnerez du temps sur le long terme gnagnagna, vous souci premier est toujours d'obtenir le résultat. Alors on revient à #overlyhonestmethods, on fait souvent ce qu'il faut pour avancer, à coups de rubban adhésif. Mais publier son code, c'est pas un peu mettre #overlyhonestmethods dans ses articles officiels ?

A quoi je répondrais qu'il faut qu'on y passe. Trop de nos résultats sont dépendants de notre code pour le cacher. Et l'effort fait aujourd'hui payera demain, avec un code mieux débuggé et plus efficace même pour nous, avec plus de facilité à retrouver ce qu'on a fait dans 5 ans quand on aura tout oublié mais que l'article sera toujours là avec son code à-peu-près propre. Oui à-peu-près parce que je pense que pour que ça marche il faut accepter qu'on ne va généralement pas avoir du code informatique de qualité professionnelle.

Alors en pratique que faire ? Demander aux journaux scientifiques de demander le code, le demander en tant qu'expert ; publier son propre code (un peu tard pour moi, je fous plus rien en programmation) ; demander à ses collègues et étudiants de publier le leur (grosse résistance en vue) ; former les étudiants a minima à la programmation propre ; participer à des initiatives comme celle d'Iddo. Et espérer que les attitudes vont changer.

Mise à jour : @JeanFred nous signale l'existence du Science code manifesto, par le Climate Code Foundation, qui traite de ces mêmes questions.