Tout d'abord, je tire mon chapeau, comme la dernière fois, à Raphaël Pierquin, Emmanuel Gaillot et Bernard Notariani qui organisent ça. Je ne suis pas sûr de la quantité de travail que ça leur demande mais en tout cas le résultat est parfait. On est comme dans un écrin : hotel parfait, repas parfaits, cadre parfait, ambiances variées et propices aux échanges. Il ne reste plus qu'aux participants à faire le reste.
Une bande de gauchos soulés à la quetsh
J'y ai découvert Bernard Stiegler et la révolution d'une économie consumériste vers une économie de la coopération. Comment l'open-source puis wikipedia ouvrent la voie vers cette révolution. J'y ai découvert que le web2.0 n'est que le balbutiement de ce que sera le monde 2.0, à commencer, par exemple, par l'énergie 2.0.
Autrement dit, ce qu'on a vu se faire dans la communauté open-source : je consomme du logiciel en même temps que je produit du logiciel. Ce qu' on a vu se répandre avec wikipedia : je consomme une encyclopédie en même temps que je produit une encyclopédie. Tout cela n'est peut-être rien comparé à ce qui est en train de se produire dans le domaine de l'énergie : je consomme de l'électricité en même temps que je produit de l'électricité. L'idée étant que la motivation personnelle pour produire est d'abord libidinale avant d'être marchande... même si elle peut être rentable.
La question suivante étant : qu'est-ce que nous, informaticiens, pouvons produire/concevoir pour amplifier ou favoriser cette révolution... là je vous passe le brainstorming de mecs bourrés ;) mais le soucis de faire plus avec moins de puissance a fortement émergé de cette conversation.
Dans la même veine, j'ai découvert le "hacker manifesto" (http://www.criticalsecret.com/n10/A%20HACKER%20MANIFESTO/index.php). Le bricoleur/bidouilleur qu'est-ce qui le motive ? L'introduction de l'agilité dans une entreprise relève-t-elle du hack ? Je fais la plupart des travaux chez moi moi-même plutôt que de passer par un artisan : je suis un hacker et nous sommes nombreux.
Ce théme s'est cloturé par une session "refaire le monde" à laquelle je n'ai pas assisté :( Références : vidéos en ligne de Bernard Stiegler, "Hacker manifesto", film "volem rien foutre al pais".
Spécifications exécutables et autres tests de recette automatisés
Nous avons partagés sur ce que nous faisions en terme de tests de recette automatisés et notamment avec fitnesse ou Concordion. Nous avons eu plutôt tendance à nous accorder sur le fait qu'il s'agissait là avant tout d'outils de communication avec le client. En particulier je retiens l'idée que le TDD, pour un surcoût nul (c'est mon point de vue) permet de réduire de 95% le nombre d'anomalies remontées lors d'une recette (constaté sur un projet réel). Les tests de recette automatisés permettent d'éliminer presque les 5% restants mais pour un coût important. Mais des tests junit ne permettent pas la discussion avec tout le monde...
J'ai beaucoup aimé la théorisation par Etienne Charignon de la notion de spécification exécutable versus spécification tout court. Pour lui, la spécification (pas forcément très formelle) est une description continue de ce que souhaite le client. La spécification exécutable est une description discrète de la même chose. Plus on prend d'échantillons plus on s'approche de la description continue. C'est pas très claire ? Possible... Ah et d'ailleurs j'ai appris qu'on ne parle pas de spécifications par les tests ou même de spécification exécutable (encore que, ça ça passe) mais plutôt de spécification par l'exemple.
Métriques
Quelles métriques utilisons-nous ? Ce que j'ai retenu des conversations c'est, qu'il s'agisse de respect des conventions de code ou de couverture du code par les tests ou de complexité cyclomatique, etc..., une métrique est et doit toujours être associée à un apprentissage (on passe au TDD : on mesure le taux de couverture, etc) et que ce qui nous intéresse dans une métrique, ce n'est pas sa valeur absolue mais son évolution. Lorsque l'apprentissage recherché est atteint, la courbe n'évolue plus. La métrique doit alors disparaître (quitte à ce qu'elle revienne plus tard) sous peine de devenir du bruit, une mesure prise de façon routinière dont on a oublié le sens.
J'ai découvert qu'une métrique peut être très simple. Par exemple chez no parking ils mesurent leur progrès en terme de test en calculant un ratio entre le nombre de lignes de code et le nombre d'assert dans les tests... à comparer avec la complexité d'un outil d'analyse de couverture de code sachant que, de toute façon, 100% de code couvert ne signifie pas 100% des cas testés.
J'ai découvert aussi que la plupart des métriques faites sur un code sont statistiquement corrélées. C'est, toujours chez no parking, ce dont ils se sont rendu compte lors d'un stage fait par un étudiant statisticien sur leurs métriques. Autrement dit, lorsqu'une métrique varie (par exemple le taux de couverture du code) dans un sens, toutes les autres métriques varient également dans ce même sens (par exemple le respect de la convention de code). Cela semble indiquer qu'une seule métrique à un instant t est réellement utile. Cela me fait penser également que la qualité ou la non qualité d'un logiciel est probablement liée à une attitude globale des gens qui contribuent à ce logiciel...
Divers
J'ai découvert le jeu du TAO. Intéressant. Je pense qu'il s'agit d'un bon support lorsqu'on cherche à "aligner" une équipe. A ne pratiquer qu'avec des gens intègrent et en confiance. Conseil : être modeste sur sa quête personnelle si on veut tirer quelque chose du jeu. Pour les détails : google.
J'ai découvert Haskel
Je reviens avec un cadavre exquis dans les bagages... mais il se fait tard, je n'en dirais pas plus.
