rm segfault

Une première pour moi. Je suis encore sous le choc...

Tux en pâte à sel

Je viens de retomber sur des vieilles photo d'un Tux en pâte à sel confectionné par mon épouse... elle est trop forte ! Ca méritait bien un billet... ;)

Manifesto for Half-Arsed Agile Software Development

C'est juste excellent : http://www.halfarsedagilemanifesto.org/

Coding dojo et terminologie

Sara Ford fait quelques précisions intéressantes sur la terminologie en karaté et sur les éventuelles correspondances qu'on peut faire ou ne pas faire lorsqu'on parle de coding dojo :

Coding is not Kata

Le consommateur n'est pas le client, c'est le produit

The consumer is not the customer, it is the product.

Autrement dit, lorsque nous utilisons, par exemple, Google, facebook, etc. nous ne sommes pas les clients de facebook. Nous sommes en fait leur produit, qu'ils vendent à leurs vrais client.

C'est une des très bonnes remarques faites par Bruce Shneier dans ce très court discours que je vous recommande : http://www.youtube.com/watch?v=I6ZkU2fUM5w

5 questions à se poser sur un projet

Voilà 5 questions à se poser pour diagnostiquer un projet que je voudrais retenir (parmi d'autres). Elles sont extraites du chapitre 2 de Crystal Clear: A Human-Powered Methodology for Small Teams d'Alistair Cockburn :

Have you delivered running, tested, and usable code at least twice to your user community in the last six months?

Did you get together at least once within the last three months for a half hour, hour, or half day to compare notes, reflect, discuss your group’s working habits, and discover what speeds you up, what slows you down, and what you might be able to improve?

Can you tell your boss you mis-estimated by more than 50 percent, or that you just received a tempting job offer? Can you disagree with your boss about the schedule in a team meeting? Can people end long debates about each other’s designs with friendly disagreement?

Does it take less than three days, on the average, from the time you come up with a question about system usage to when an expert user answers the question? Can you get the answer in a few hours?

Can you run the system tests to completion without having to be physically present? Do all your developers check their code into the configuration management system? Do they put in a useful note about it as they check it in? Is the system integrated at least twice a week?

Alistair m'a tuer

Extrait du chapitre 2 de Crystal Clear: A Human-Powered Methodology for Small Teams d'Alistair Cockburn :

Even with the best of intentions, developers will work on things that only randomly bring business value if they are not told what will provide business value.

Je suis un peu désespéré de lire ça mais bon... heureusement il y a d'autres choses intéressantes à retenir de cet ouvrage.

agilité, auto-organisation, charrue et boeufs

The best architectures, requirements, and designs emerge from self-organizing teams. (http://agilemanifesto.org/principles.html)

Je suis 100% d'accord avec ce principe.

Mais attention à ne pas mettre la charrue avant les boeufs. Une équipe auto-organisée ne se décrète pas, elle se constate. On peut mettre en place les éléments qui lui permettront de s'auto-organiser, bien sûr, mais quels sont-ils, ces éléments ? Et qui les met en place ? Un leader ? Un manager ? Un chef ? Mais alors cette équipe est-elle auto-organisée ? Ou est-ce que ce qu'on appelle une équipe auto-organisée est simplement une équipe livrée à elle-même ?

J'ai peur que le principe ci-dessus soit parfois mal interprété :
- OK ! Il me suffit de les laisser s'organiser comme ils veulent et ils vont me pondre un super truc.

Ce qui est cher est souvent rare mais tout ce qui est rare n'est pas forcément cher.

Si ce principe nous dit que, souvent, les meilleures choses ont été produites par des équipes auto-organisées, il ne nous dit pas qu'il suffit de livrer une équipe à elle-même pour qu'elle produise les meilleures choses.

Dommage que, parmi les 12 principes du manifeste agile, celui de l'équipe auto-organisée revienne si souvent dans les conversations et celui-ci si peu souvent :

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Si j'étais cynique je dirais que c'est bien pratique, pour un manager, une équipe auto-organisée mais que, a contrario, trouver des gens motivés et accorder sa confiance, est un exercice infiniment plus complexe.

SOAP-dust, un client SOAP en Java avec moins de 72 dépendances

La version 0.0.24 de SOAP-dust est disponible sur sourceforge.

Si vous développez en Java. Si vous êtes obligé de faire des appels SOAP vers des webservice externes. Si vous en avez marre de dépendre de 72 jar différents pour pouvoir faire un appel SOAP. Si vous en avez marre de devoir lancer un générateur de code Java avant de pouvoir faire un appel SOAP.

Alors SOAP-dust est fait pour vous. Tentez le coup.

La version 0.0.24 souffre encore de quelques défauts de jeunesse qui disparaitront rapidement. Mais elle est déjà utilisée avec succès sur plusieurs services en production et je pense qu'elle mérite donc qu'on y jette un oeil dès maintenant.

Amusez vous bien !

Where Do Security Policies Come From?

Un article cité par Schneier qui tente de comprendre le lien entre les contraintes qu'un site web impose à ses utilisateurs pour la composition de leur mot de passe et la sensibilité des données stockées sur ce site : Where Do Security Policies Come From?

Au final il semble qu'il n'y ait aucun lien. Les sites qui imposent le plus de contraintes à leurs utilisateurs pour la composition de leurs mots de passes sont simplement les sites qui peuvent se permettre d'enquiquiner leurs utilisateurs sans risquer de perdre ces derniers au profit d'un autre site :

Our analysis suggests that strong-policy sites do not have greater security needs. Rather, it appears that they are better insulated from the consequences of imposing poor usability decisions on their users.


Une autre lecture instructive au sujet des mots de passe : Security Myths and Passwords.

Le mythe du mois-homme (encore et encore)

Toujours dans ma re-lecture de Le mythe du mois-homme de F. P. Brooks. Et encore quelques éléments que j'ai envie de retenir du chapitre 3...

Au sujet de l'importance de la compétence :

Dans l'une de leurs études, Sackman, Erikson et Grant ont mésuré les performances d'un groupe de programmeurs expérimentés. Rien qu'à l'intérieur de ce groupe, le rapport entre les meilleurs et les plus mauvaises performances étaient en moyenne de 10 pour la productivité et, étonnamment, de 5 pour la vitesse du programme et de la mémoire occupée ! Bref, le programmeur gagnant 20 000 $ par an peut fort bien être 10 fois plus productif que celui qui en gagne 10 000. L'inverse peut aussi être vrai. Les données ne montraient absolument aucune corrélation entre l'expérience et les performances. (Je doute que ce soit vrai partout.) p.24

Employer le moins de monde possible et des gens compétents :

La plus grosse partie du coût est [...] due à la communication et à la correction (le débogage) des effets néfastes d'un manque de communication. C'est une autre bonne raison pour vouloir construire un système avec aussi peu de monde que possible. Et, de fait, la plupart des grands projets logiciels montrent que la force brutale est coûteuse, lente, inefficace, et produit des systèmes qui souffrent d'un manque d'intégrations.[...]

La conclusion est simple : si une équipe de 200 hommes a 25 managers qui sont les programmeurs les plus expérimentés et les plus compétents, limogez les 175 trouffions et remettez les managers à la programmation. p. 24

Malheureusement... une petite équipe pointue [...] ne va pas assez vite pour les projets vraiment grands. Il présente alors la proposition de Mills (l'équipe chirurgicale) :

Mills propose que chaque segment d'un gros travail soit attaqué par une équipe, mais que celle-ci soit organisée comme une équipe chirurgicale plutôt que comme un groupe d'équarisseurs. Au lieu de laisser chaque membre de l'équipe tailler dans le problème, on laisse opérer une seule personne, et les autres lui fournissent toute l'aide susceptible d'améliorer son efficacité et sa productivité. p. 25

Il fait remarquer que :

[...] dans l'équipe conventionnelle, les partenaires sont égaux, et les inévitables divergences d'avis qui surviennent doivent être discutées et aplanies par des compromis. Comme le travail est divisé les différences d'avis sont confinées à la stratégie globale et aux interfaces, mais elles sont motivées par des conflits d'intérêts[...]. Dans l'équipe chirurgicale, il n'y a pas de conflits d'intérêts et les divergences d'opinions sont tranchées unilatéralement par le chirurgien. Ces deux différences - absence de division du travail et relation supérieur-subordonné - permettent à l'équipe chirurgicale d'agir uno-animo. p. 28

Il introduit ensuite la notion d'intégrité conceptuelle qui est le centre de plusieurs des chapitres suivants. Au passage, il présente l'architecte comme le garant de cette intégrité conceptuelle :

[...] l'ensemble du système doit également posséder une intégrité conceptuelle, et [...] cela exige qu'un même architecte-système le conçoive de A à Z. p. 29

Cet extrait du guide de la cathédrale de Reims au début du chapitre 4 résume bien l'importance que Brooks accorde à l'intégrité conceptuelle et à la compétence :

Cette grande église est une incomparable œuvre d'art. Elle ne contient ni aridité, ni confusion dans ses principes. Elle représente l'apogée d'un style. Elle est due au travail d'artiste qui avaient compris et assimilés toutes les réussites de leurs prédécesseurs, et qui maîtrisaient totalement les techniques de leur temps, sans se croire obligés de faire étalage de leur habilité par des prouesses de style. Ce fut sans doute Jean d'Orbais qui conçut le plan d'ensemble du batiment. Ce plan fut respecté au moins dans les grandes lignes par ses successeurs. C'est là une des raisons de l'extrême cohérence et de l'unité de l'édifice. p. 33

Un architecte garant de l'intégrité conceptuelle du système... beaucoup tremblent déjà devant les dérives possibles. Brooks les a déjà constatée et s'en inquiète déjà en 1975 :

Comment peut-on parvenir à l'intégrité conceptuelle ?

Cela n'implique-t-il pas l'existence d'une élite, d'une aristocratie d'architecte et d'une horde d'implémenteurs plébéiens aux talents et idées créatives étouffées ?

Comment peut-on empêcher les architectes de sortir des limites de l'épure avec des spécifications ruineuses ou impossibles à implémenter ?

Comment s'assurer que chaque petit détail d'une spécification architecturale est communiquée à l'implémenteur, correctement compris par lui, et fidèlement incorporé au produit ? p.34

Terrifiant d'actualité....

Le mythe du mois-homme (encore)

Je relis Le mythe du mois-homme de Frederick P. Brooks, Jr. La première édition date de 1975 et ce qu'on y lit est toujours d'actualité et semble toujours ignoré aujourd'hui. Je reproduis ici quelques extraits qui me paraissent intéressants et qu'on découvre dès les premières pages. En commençant bien sûr par...

loi de Brooks : Ajouter des gens à un projet en retard le retarde encore davantage.

Si chaque tâche doit être coordonnée avec chaque autre, l'effort [de communication] augmente en n(n-1)/2, où n est le nombre de taches. Trois travailleurs réclament trois fois plus d'intercommunication que deux, quatre en réclament six fois plus que deux. [...] si [...] il faut des conférences à trois, quatre, etc., [...] L'effort supplémentaire de communication peut complètement annihiler les gains apportés par la division de la tache[...] A ce stade, ajouter des hommes allonge le délai au lieu de le raccourcir. p. 15

Quelques références quantitatives à garder en mémoire :

V. A. Vyssotsky des laboratoires Bell estime que dans un grand projet, on peut augmenter la main-d'œuvre de 30 % par an. Si on dépasse ce chiffre, on freine, ou pire, on inhibe la mise en place des structures informelles essentielles au projet [...] note 1, p. 15

[répartition empirique du temps lors de la planification d'un projet] :

1/3 de planification ;

1/6 de codage ;

1/4 de test unitaire de composants isolés et de tests d'intégration préliminaires ;

1/4 de test d'intégration général, avec tous les composants en main. p. 16

Agile Open France 2010

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.