5h du matin

Stack Overflow en beta publique

2008-09-15T21:58:00.005+02:00

Jeff Atwood et Joel Spolsky nous dévoilent enfin leur projet commun dont ils parlent depuis plusieurs mois déjà: Stack Overflow.

Il s'agit d'un site pour développeurs en quête de réponses. S'ils n'y trouveront pas nécessairement le bonheur et l'amour, ils y trouveront en tout cas d'ores et déjà un grand nombre de questions techniques auxquelles d'autres développeurs ont répondu, comme par exemple "Comment itérer en C# sur un result set après une requête SQL?" ou "Comment intégrer les tests unitaires dans un projet existant?"

Le principe est simple: n'importe qui peut poser une question, et n'importe qui peut y répondre. Même sans avoir créé de compte! Les utilisateurs inscrits peuvent ensuite voter pour une question ou une réponse, afin de faire remonter les meilleurs contenus. Les utilisateurs enregistrés gagnent des points de réputation à chaque fois que l'une de leurs questions ou réponses est votée vers le haut, et passé un certain seuil de réputation, l'utilisateur peut modifier les questions et les réponses, ce qui permet de corriger les réponses au fur et à mesure qu'elles deviennent obsolètes (ce qui peut aller vite).

J'ai eu la possibilité de participer à la beta privée du site depuis plusieurs semaines, et je dois dire que le site fonctionne très bien. Développé par Jeff Atwood et son équipe, le site est réactif et très simple à utiliser. Et surtout, ça marche! On pose une question, et on voit apparaître les réponses dès les premières secondes. Pas de débat (le site est construit de telle sorte à le décourager), et si la question a été posée et que la réponse a été fournie, on les trouve instantanément. C'est véritablement impressionnant.

Alors développeurs anglophones, allez faire un tour sur Stack Overflow, et poser vos question - ça en vaut la peine. Et si cela ne vous dit rien, et que votre anglais est correct, écoutez tout de même le podcast entre Joel et Jeff, vous apprendrez plein de choses.

Quand Joel change d'avis sur les interfaces graphiques

2008-07-02T22:35:00.001+02:00

Joel Spolsky, de JoelOnSoftware, vient de publier un tout petit billet qui dit en substance: il ne faut ni cacher, ni désactiver les entrées d'un menu lorsque l'action correspondante ne peut être effectuée.

Le fait de cacher des éléments d'une interface est généralement considéré comme une mauvaise pratique. Il m'arrive souvent de chercher, dans des logiciels complexes comme OpenOffice ou Live, où diable cette fonctionnalité qui avait l'air si prometteuse à bien pu se planquer. C'est déjà suffisamment frustrant de naviguer dans les menus alors que j'ai du travail à faire, sans qu'en plus on m'enlève toute chance de retrouver ladite fonctionnalité parce que la commande n'est même plus là!

Jusque là, je suis d'accord avec Spolsky. Mais voyons ce qu'il nous recommande à la place:

Instead, leave the menu item enabled. If there's some reason you can't complete the action, the menu item can display a message telling the user why.

Sous quelle forme? Info-bulle? Boîte de message? Barre d'information en bas de la fenêtre, à l'autre bout du monde par rapport à l'endroit où l'utilisateur regarde?

Tout de suite, je me suis souvenu d'un essai qui m'avait marqué, où Spolsky assénait avec assurance que les utilisateurs ne lisent pas:

This may sound a little harsh, but you'll see, when you do usability tests, that there are quite a few users who simply do not read words that you put on the screen. If you pop up an error box of any sort, they simply will not read it. This may be disconcerting to you as a programmer, because you imagine yourself as conducting a dialog with the user. Hey, user! You can't open that file, we don't support that file format! Still, experience shows that the more words you put on that dialog box, the fewer people will actually read it.

Mettons que la commande "coller" ne peut pas être exécutée à un moment donné. Comment expliquer à l'utilisateur qu'il ne peut pas coller dans Paint .NET les 26 colonnes de nombres qu'il vient de copier dans Excel de manière à ce que 1) il lisent l'explication, et 2) il la comprenne?

Moi, pour ma part, je ne lis pas les messages. Et comme je suis un utilisateur comme un autre, je ne m'attends pas à des miracles sur ce front-là.

Pire encore, faut-il apprendre à l'utilisateur que chaque élément actif à l'écran peut lui envoyer un message à la figure plutôt que de produire le résultat attendu? Pas très bon pour l'encourager à explorer les fonctionnalités du logiciel...

D'autant que tout le monde grise des éléments des menus lorsqu'ils ne sont pas applicables. Or à la même époque, Spolsky nous vantait les mérites de la constance dans les interfaces graphiques:

If Microsoft is doing it in a popular program like Word, Excel, Windows, or Internet Explorer, then millions of people are going to think that it's right, or at least, fairly standard, and they are going to assume that your program works the same way. Even if you think (as the Netscape 6.0 engineers clearly do) that Alt+Left is not a good shortcut key for "Back", there are literally millions of people out there who will try to use Alt+Left to go back, and if you refuse to do it on some general religious principle that Bill Gates is the evil smurf arch-nemesis Gargamel, then you are just gratuitously ruining your program so that you can feel smug and self-satisfied, and your users will not thank you for it.

And don't be so sure it's not right. Microsoft spends more money on usability testing than you do, they keep detailed statistics based on millions of tech support phone calls, and there's a darn good chance that they did it that way because more people can figure out how to use it that way.

Alors au vu de tout ça, que penser de ce brusque revirement? Je respecte beaucoup les conseils de Spolsky. A tel point que je suis prêt à lui accorder le bénéfice du doute: est-ce une simple provocation? Peut-être nous donnera-t-il lui-même sa raison d'ici peu.

Tests unitaires - test ou conception?

2008-06-28T13:17:00.002+02:00

Karl Seguin vient de publier un livre, Foundations of Programming, disponible en téléchargement. J'ai feuilleté un peu le PDF, et notamment le paragraphe intitulé "Why Wasn't I Unit Testing 3 Years Ago?" - littéralement "Pourquoi n'utilisais-je pas les tests unitaires il y a 3 ans?".

I had misconception about the goals of unit testing. As I’ve already said, unit testing does improve the quality of a system, but it’s really all about making it easier to change / maintain the system later on. Furthermore, if you go to the next logical step and adopt Test Driven Development, unit testing really becomes about design. To paraphrase Scott Bellware, TDD isn't about testing because you're not thinking as a tester when doing TDD – you’re thinking as a designer.

Lorsqu'on écrit un test unitaire, selon Karl Seguin, on ne porte pas la casquette du testeur, mais bien celle du concepteur. L'idée va à l'encontre de l'intuition, bien sûr: dans "test unitaire", il y a "test", et les tests c'est d'habitude plutôt la queue du train, à l'opposé de la conception.

Mais l'idée est non seulement rafraîchissante: elle sonne juste! Chez Ableton, nous n'utilisons pas les tests unitaires de manière systématique, mais cela ne m'empêche pas d'en avoir une petite collection dans mon coin, et je dois bien dire que celles de mes fonctionnalités qui sont testées de cette manière sont aussi matérialisées par les classes les plus indépendantes et les mieux conçues. En effet, comment tester une classe qui en requiert 14 autres? Et notez bien qu'on peut retirer ces bénéfices même sans pratiquer le TDD, c'est-à-dire sans écrire ses tests avant le code à tester.

Je n'ai pas lu le reste de l'ouvrage, mais je pense qu'il contient quelques de bons conseils. Amis de Shakespeare, jettez-y un coup d'œil.

Bien utiliser assert()

2008-06-24T20:55:00.000+02:00

Début 2006, j'ai écrit un article intitulé Asserter n'est pas jouer, qui traitait des assertions en C++. Avec deux ans d'expérience en plus dans les pattes, je me rends compte qu'il est grand temps de peaufiner, voire de corriger mon avis sur la question. C'est d'autant plus utile que peu de développeurs savent vraiment utiliser les assertions. En effet, la gestion des erreurs fait partie, avec la programmation concurrente, de ces domaines de la programmation dont la difficulté est largement sous-estimée.

A quoi servent les assertions?

La définition classique, du genre "les assertions permettent de détecter lorsqu'une condition qui doit être vraie n'est pas vérifiée", est à peu près aussi utile qu'un GPS dans un tunnel: elle nous dit ce que sont les assertions, mais pas comment les utiliser. Les assertions servent à une seule chose: vous taper sur les doigts lorsque vous ou l'un de vos collègues introduisez un bug dans le code. Ni plus, ni moins.

Si votre code suppose quelque chose d'une variable, assertez, et faites comme si tout allait bien. La pire chose à faire, c'est d'essayer de retomber sur ses pieds en corrigeant des valeurs non valides ou en gérant des conditions bizarres "au cas où": non seulement vous aurez caché le bug, mais vous l'aurez même rendu plus difficile encore à détecter. C'est mal !

Bug, bug, bug. Une fois que ceci est rentré dans le crâne, on comprend deux choses:

On ne peut pas s'en servir pour valider une condition influencée par une donnée venant "des autres".
Supprimer les assertions dans le code de production est une aberration.

C'est qui, les autres ?

Les autres, par rapport à moi, ce sont tous ceux qui ne sont pas dans mon équipe de développement. Il peut s'agir aussi bien de l'utilisateur final, de l'autre côté de l'écran ou de mon API, que d'un fournisseur d'une classe ou d'une fonction que j'utilise moi-même. Pour moi, tout ce qui ne vient pas du code produit par mon équipe est suspect, mais n'est pas de mon ressort. On ne peut donc pas utiliser les assertions pour :

valider un paramètre d'entrée si la personne susceptible d'utiliser la fonction n'a pas accès au code de celle-ci,
vérifier que l'utilisateur, ce cloporte mal éduqué, a bien entré un nombre entre 1 et 10, comme c'est marqué en gras avec du texte rouge qui clignote à deux pixels de la zone de saisie,
vérifier qu'un fichier, si important soit-il pour l'application, est bien présent et contient des données valides,
vérifier que malloc() renvoie bien un pointeur non nul (notez que dans Asserter n'est pas jouer, j'avais testé la valeur de retour de new, qui d'après le standard doit lancer une exception si l'allocation échoue, mais j'utilisais à l'époque Visual C++ 6.0 qui ne s'y conformait pas sur ce point-là)
répandre la paix sur terre

Par contre, pour toutes les conditions d'erreur où il est possible d'aller trouver le fautif dans un bureau avoisinant, l'assertion est le meilleur outil. Si en plus, en cas d'assertion qui échoue, vous en profitez pour lui verser du Tabasco dans son café, le respect pour les assertions montera en flèche dans votre équipe.

Pourquoi faut-il laisser les assertions dans le code de production ?

Par code de production, j'entends la version compilée en mode "release". Toutes les invocations de la macro assert() standard disparaissent comme par enchantement lorsque DEBUG n'est pas défini. Le raisonnement est qu'une fois le code bien testé, on peut se passer de ces vérifications et gagner ainsi en performance.

C'est très très mal !

C'est vrai, il faut du temps pour accepter que que son code ne sera jamais totalement, complètement testé. C'est cette fameuse humilité à laquelle Jeff Atwood fait référence dans son blog Coding Horror. Mais des bugs, nous en laisserons toujours derrière nous. Du coup, la question change: il ne s'agit plus de savoir quand l'application sera complètement débuggée, mais plutôt de savoir comment elle doit réagir en présence d'un bug. Les assertions servent justement à ça.

La bonne réponse, aussi désagréable soit-elle, c'est de tuer l'application le plus vite possible. C'est le rôle de l'assertion: après avoir détecté un bug, elle doit planter l'application en exécutant un minimum de code. La solution est dramatique, mais ne pas le faire peut être pire encore. Vous pouvez par exemple corrompre des données. C'est le pêché ultime dans le mode du logiciel, qui vous apporte malédiction à vous et votre descendance sur sept générations. Mieux vaut planter avec panache que de cacher une erreur.

Toujours pas convaincu? Imaginez que vous programmez un système médical de respiration assistée. Les petits systèmes embarqués comme ça ont souvent un mécanisme qui permet de détecter que l'application s'est terminée et la redémarrent aussi sec. Mettons qu'au bout de 24h de fonctionnement, l'une de vos assertions détecte une erreur dans la fonction qui détecte les seuils de débit pour le déclenchement. Vous ne voulez surtout pas asphyxier votre pauvre patient! En tuant le programme, votre assertion lui permettra de redémarrer dans un état sain.

Il n'est d'ailleurs pas souhaitable d'implémenter des assertions sous forme d'exception. Même si celle-ci remonte jusqu'au main(), elle déclenchera sur son chemin une flopée de destructions d'objets. Or votre programme à ce moment-là, il faut bien le dire, il est bien pourri, et même les destructeurs peuvent faire des bêtises! Moins on exécute de code, mieux c'est. Votre nouvelle meilleure amie: abort().

Apprendre de ses erreurs

Mais s'il faut terminer au plus vite, c'est en revanche dommage de manquer l'occasion d'avoir plus d'info sur le problème. En implémentant votre propre mécanisme d'assertions, vous pourrez rassembler toute l'information qu'il vous faut, empaqueter tout cela à votre guise et vous le renvoyer directement chez vous (ou si vous êtes très fort, vous le faire envoyer par e-mail par l'utilisateur). En développement, profitez-en pour faire intervenir le débuggeur. En production, soyez sympa, évitez à votre utilisateur la surprise de voir votre application disparaître subitement, et montrez-lui au moins un petit message en lui expliquant bien que c'est de votre faute.

Et si vous êtes le malheureux développeur du ventilateur mécanique, déclenchez donc une petite alarme, histoire qu'une infirmière puisse vérifier l'état du patient que vous venez de laisser tomber...

Comprendre les niveaux de garantie de sécurité face aux exceptions

2008-06-18T07:49:00.007+02:00

Le C++ est un langage pour experts. Chaque ligne de code doit déclencher un certain nombre de réflexes chez le programmeur. Ceux qui viennent du C en ont déjà intégré un grand nombre: les pointeurs doivent être valides, les diviseurs ne peuvent pas être nuls, l'utilisateur peut entrer des valeurs fausses, incorrectes voire même dangereuses, et même les bonnes vieilles chaînes de caractères nécessitent une gymnastique mentale à base de poteaux et de barrières pour allouer la bonne quantité de mémoire et s'assurer qu'on trouve bien un zéro au bout.

Je me considérais moi-même avant comme quelqu'un de raisonnablement expert en C++ jusqu'à ce que je lise le chapitre "Exception safety issues and techniques" (en français: problèmes et techniques liées aux exceptions) du livre de Herb Sutter Exceptional C++.

Dans ma tête, connaître les exceptions se limitait à comprendre comment fonctionne un try ... catch. Mais en lisant ce chapitre, où M. Sutter explique au lecteur pâlissant que dans une simple fonction qui concatène des chaînes de caractères, il peut voler plus d'exceptions que dans un livre de grammaire allemande, je me suis rendu compte que ces bestioles méritaient beaucoup plus de respect de ma part, et qu'on ne pouvait raisonnablement s'affirmer expert avant d'avoir au moins intégré tout cela.

Très vite lorsqu'on s'intéresse aux exceptions, deux problèmes majeurs émergent:

Le programmeur qui doit signaler une erreur doit choisir son mécanisme consciencieusement. Valeur de retour ou exception? Si exception, quelle type d'objet lancer? Faut-il créer sa hiérarchie de classes d'exceptions ou faut-il au contraire utiliser au maximum les classes fournies par la bibliothèque standard (std::exception & co.)?
Le programmeur qui doit utiliser une fonction ou une classe susceptible de lancer une exception doit écrire son code en conséquence, de manière à ce qu'une exception n'endommage pas l'état du programme de manière incontrôlée.

Cet article discute du second point. Choisir une stratégie en cas d'erreur est, je dois bien l'avouer, un sujet sur lequel je ne me sens pas encore à l'aise, en tout cas pas suffisamment pour blogger dessus. Je vois ça un peu comme les threads: beaucoup prétendent maîtriser le sujet, mais les vrais experts sont rares.

Par contre écrire du code qui doit jouer le jeu en présence d'exceptions, je le fais tous les jours au bureau. L'idée est que, tout comme l'implémentation d'une fonction que j'utilise m'intéresse moins que le contrat qu'elle prétend honorer, je préfère ne pas savoir si telle ou telle fonction ou méthode lance des exceptions ou pas. Par contre, ce qui m'intéresse, c'est de savoir quel niveau de sécurité est garanti par mon code et par celui des autres face à une exception. Pour cela, il faut comprendre les 3 niveaux de garantie de sécurité, parfois appelées "garanties Abrahams", du nom de celui qui les a formalisé.

Les niveaux de garantie de sécurité face aux exceptions

Prenons un objet o de la classe C, et la méthode C::f() associée. La méthode f() peut se comporter de quatre façons différentes en matière d'exceptions:

Si dans le code de la méthode f() une exception est lancée, l'état du programme est corrompu. Il est alors quasiment impossible de réutiliser l'objet o par la suite, et même sa destruction peut poser problème. La méthode f() ne donne aucune garantie de sécurité.
Si une exception est lancée de f(), mais qu'une fois l'exécution de f() est finie, l'objet o est toujours dans un état valide (je peux par exemple réinitialiser l'objet ou lui affecter une nouvelle valeur sans risque de plantage), alors la méthode f() offre la garantie de base: une exception laisse l'objet dans un état valide, même si cet état n'est pas forcément prévisible.
Si en plus d'offrir la garantie de base, f() se comporte en cas d'échec comme si elle n'avait jamais été appelée, elle offre la garantie forte: l'état de l'objet reste inchangé si une opération ne peut être complétée.
Si f() ne peut jamais lancer d'exception, on parle de garantie no-throw.

Ces quatre niveau de garantie vont dans l'ordre croissant de sérénité pour l'utilisateur de la méthode f(). On aimerait bien sûr que toutes les fonctions du monde offrent la garantie no-throw, mais c'est un peu utopique. A défaut, on préfère tout de même en rester le plus proche possible, et on ne devrait jamais utiliser de fonction qui n'offre aucune garantie de sécurité: cela signifie que si une exception s'y produit, la seule option qui reste est de terminer le programme illico presto avant qu'il ne corrompe les données de l'utilisateur.

A noter que parfois, monter d'un cran en matière de garantie de sécurité peut avoir des conséquences néfastes pour la performance, parce qu'il faut alors faire plus de travail et/ou utiliser plus de mémoire. Il peut donc y avoir des raisons parfaitement valables pour se limiter par exemple à la garantie de base au lieu de fournir les garanties forte ou no-throw.

Exemples

Lorsque je joue à la Playstation (PS2), je vois régulièrement des écrans de sauvegarde qui me demandent poliment de ne pas éteindre la console le temps de l'opération. Typiquement, voilà une opération qui n'offre aucune garantie de sécurité: si une "exception" se produit pendant son exécution (le chat fait tomber un pot de fleurs sur l'interrupteur de la multiprise), le fichier qu'aura tenté d'écrire le jeu sera probablement complètement inutilisable. Je ne pourrai plus jamais le relire, et pire encore, il se pourrait même que la carte mémoire entière soit devenue inutilisable. C'est mal.

Il vous est sans doute déjà arrivé de vouloir copier un gros répertoire d'un disque à un autre, et voir apparaître en cours de route une erreur vous disant que pour une raison ou pour une autre, une erreur s'est produite lors de la copie. Tous les OS que je connais offrent pour une copie récursive d'un répertoire la garantie de base: la copie ne sera peut-être pas complète, je ne saurais même pas forcément quels fichiers auront été copiés et lesquels doivent encore l'être à moins d'aller voir par moi-même et compter à la main, mais au moins je sais que ni mon disque ni le système de fichiers n'auront été endommagés. Je peux effacer le répertoire cible pour recommencer, ou copier le reste des fichiers à la main, etc. Pas trop mal.

Lorsque vous retirez de l'argent à un distributeur automatique de billets, il peut se passer plein d'"exceptions": vous pouvez vous tromper de code PIN, votre banque peut vous refuser le retrait, il peut y avoir une coupure de courant ou de communication avec la banque, etc. Dans tous les cas, si vous n'avez pas l'argent en main à la fin de l'opération, vous ne voulez surtout pas que la somme soit débitée de votre compte! Et, heureusement, c'est aussi bien le cas: soit une transaction réussit complètement et l'argent est passé de votre compte à votre main, soit elle échoue complètement et tout l'argent est resté sur votre compte. C'est ça, la garantie forte. C'est bien.

Les opérations offrant la garantie no-throw sont plus rares, mais en tant que programmeur, vous en avez quelques-unes à votre disposition. Affecter une valeur à un type de base, genre x = 10 dans le cas ou x est un int, en est une. Autre exemple: un destructeur ne devrait jamais lancer d'exception, et pourtant les destructeurs font souvent des choses complexes, comme par exemple désallouer de la mémoire. Qu'à cela ne tienne, désallouer de la mémoire revient souvent à changer les valeurs de quelques pointeurs, ce qui ne lance pas d'exception. Parfait!

Conclusion

Lorsque vous écrivez une fonction, ayez en tête le niveau de garantie de sécurité qu'elle offre face aux exceptions. Ayez aussi en tête celles des fonctions que vous utilisez, et notamment celles des fonctions de la STL. Rappelez-vous que lorsque vous utilisez des templates, vous pouvez vous retrouver avec un type dont le constructeur de copie, l'opérateur d'affectation ou encore l'opérateur d'égalité peuvent lancer des exceptions.

Si l'anglais ne vous pose pas de problème, lisez Exceptional C++, qui est très bien écrit et contient quantité de conseils formidables (contrairement à ce que laisse penser le titre, le livre ne parle pas que d'exceptions en C++). Ou à défaut, stay tuned comme ils disent là-bas, car il y aura sans doute d'autres articles sur le sujet ici-même.

Mon Carnet et Moi

2008-06-05T03:41:00.005+02:00

De la méthode, que diable!

L'autre jour je flânais mollement sur la toile, lorsqu'un article de Laurent Brixius attira mon attention: le titre mentionnait la méthode Getting Things Done, une méthode pas-à-pas pour booster sa productivité personnelle.

Getting Things Done... j'avais déjà entendu parler de cette méthode de David Allen. En fait, j'avais même plus d'une fois hésité à acheter le bouquin. Le concept, pour un dispersé du bulbe comme moi, est bigrement attirant: fini les petites choses importantes jamais faites, fini les oublis en faisant les courses, fini les retards dans les projets personnels et professionnels. Il suffit d'appliquer cette méthode et ta daaaa!

Des méthodes comme ça, à la Fnac, section management, vous en trouverez plein! Les Américains, qui ont un esprit bien plus pragmatique que nous autres Européens, n'ont semble-t-il pas trop de problèmes avec ce type de démarches qui mêlent techniques de management et style de vie, et qui brouillent un peu les frontières entre les vies pro et perso. Du coup ils sont vraiment très forts pour écrire ces ouvrages, alors que des ouvrages similaires par des Français sont en général aussi palpitants que le Ginette Mathiot.

Je suis suffisamment pragmatique pour que ces méthodes attirent mon attention. D'ailleurs un jour, dans un moment de faiblesse, seul et vulnérable, j'ai craqué: j'ai acheté Les 7 habitudes de Stephen R. Covey. Le titre entier: "Les 7 habitudes de ceux qui réalisent tout ce qu'ils entreprennent".

J'ai bien entrepris de le lire, mais j'ai vite réalisé que je n'aimais pas ça.

Non mais franchement. Ma vie n'est pas un bœuf bourguignon! Je ne la vis pas avec la recette sous les yeux, à faire pas-à-pas comme l'expert à dit. Non, je ne crois pas qu'on puisse changer sa vie en appliquant les méthodes de quelqu'un qui a vu la lumière, lui. Il s'agit d'une démarche trop personnelle pour qu'on me colle le résultat de celle d'un autre, tout conseiller de Bill Clinton qu'il soit.

Mais tout de même, ne jetons pas le bébé avec l'eau du bain. L'ouvrage de Covey, ou du moins le tiers que j'en ai lu, m'a tout de même offert plein de pistes de réflexion intéressantes. Et puis quand quelqu'un comme Allen passe toute sa journée à réfléchir à comment get les things done (et sans stress), il y a forcément de bonnes choses à prendre au final, même pour un sceptique.

Vive les listes!

Par curiosité, j'ai suivi également le lien vers la méthode Zen To Done, une sorte de version "light" de GTD. Ok, ça reste une méthode-miracle. Il y en a moins que chez Allen, mais je note que cette méthode-ci est gratuite alors qu'elle propose 3 habitudes de plus que chez Covey. D'ailleurs, le blog entier est rempli d'articles du genre "18 conseils pour réussir votre vie de couple", "les huit gestes qui sauvent quand on se brosse les dents" ou "47 façons d'être heureux".

J'ai lu néanmoins. Mon cas est tellement désespéré que je me suis demandé si je ne pouvais pas au moins adopter une seule habitude qui aurait déjà un effet positif clair. D'ailleurs, Zen To Done me conseille de ne pas adopter toutes les habitudes d'un coup, et je trouve ça un très sage conseil.

J'ai opté pour les habitudes 1 et 2: tout noter, et trier tous les jours.

J'ai un Palm Tungsten T5 depuis plusieurs années, et comme carnet d'adresses, c'est vraiment très pratique. L'agenda aussi est bien, et au début j'utilisais un peu l'application "Tasks", sorte d'utilitaire ultra-slim pour gérer des petites listes de choses à faire. Sauf que, c'est plus fort que moi, je n'aime pas écrire dans mon Palm. C'est bien plus lent et difficile que d'écrire sur du papier.

C'est pour cela que la technique du "double-buffering" pour les tâches à faire est une idée géniale. J'ai ressorti mon vieux carnet Moleskine que j'utilisais bien trop peu pour la qualité de l'objet, et je m'y suis mis:

Dès que je pense à quelque chose, je le note dans le carnet, et je dessine une petite case vide en début de ligne. 3 secondes chrono, imbattable.
Le matin avant de partir et le soir en rentrant, je reporte toutes les tâches dont la petite case est vide dans le Palm (par l'intermédiaire du logiciel pour PC, qui est bien plus confortable pour la saisie). Si c'est rapide, je le fais tout de suite. Et hop! je peux cocher la case.

Cette dualité entre outil rapide mais linéaire et outil plus sophistiqué qui permet de faire le tri est véritablement géniale. Cocher des cases à la pelle à un effet incroyable sur le moral: on a vraiment l'impression d'avoir travaillé! Je sais, c'est débile, mais c'est terriblement satisfaisant.

C'est tellement facile et efficace que j'ai étendu le concept. En tout, j'ai deux carnets et trois outils électroniques. J'ai mon Moleskine pour les tâches perso, et mon carnet Ableton pour le boulot. Nous avons de beaux carnets noirs à couverture rigide avec le ruban marque-page et le logo de la boîte en relief sur la couverture. Là encore c'est idiot, mais avoir un bel objet plutôt qu'un carnet Carrefour qui se désintègre en trois semaines (pardon, qui se bio-dégrade), ça me motive d'autant plus à l'utiliser.

De mon Moleskine, les tâches vont soit dans le Palm, soit dans ma feuille Excel qui me sert d'outil de planning pour mon logiciel perso. Celles de mon carnet Ableton atterrissent dans notre outil interne de gestion des tâches de développement, qui est celui que j'aime le moins, sans doute parce qu'il est bien plus complexe et lent à utiliser.

D'ailleurs, on ne peut pas vraiment gérer les tâches de développement comme on gère une liste de courses. Quand je note "acheter du lait" ou "mettre des patins sous chaises", j'ai toute l'info nécessaire pour réaliser la tâche. Et puis c'est tout ce que je peux afficher en une ligne sur mon Palm. Quand je note "garbage collector concurrent temps-réel", j'aime bien découper le boulot en sous-tâches, ça me détend un peu, d'autant plus que c'est la seule façon d'avoir une estimation du temps de développement qui vaut quelque chose.

Mais alors tout ça, est-ce que ça marche? Je dois bien avouer que oui! Cela fait plus d'un mois que je le fais, ce qui est un record dans la triste histoire de mes tentatives de changer mes habitudes. La simplicité du procédé, le plaisir de cocher plein de cases tous les jours (ou presque) et mon attrait pour les beaux objets se combinent à merveille pour combattre ma tendance naturelle à tout oublier.

Et du coup, je n'oublie plus que la moitié de ce que je pouvais oublier avant. Quand je vous dis que ça marche!

Musikmesse 2008 - Jeunes Pousses et Vieux Routiers

2008-03-16T12:35:00.002+01:00

Cette année encore, un petit groupe de volontaires téméraires chez Ableton a pu se rendre à la Musikmesse à Francfort pour fureter, découvrir, écouter, observer, s'enthousiasmer, s'agacer et discuter des nouveautés dans l'industrie musicale. Lever à 5h du matin (décidément) et retour sur Berlin à 22h, ce fut une grosse journée, mais, pour votre serviteur, très riche en rencontres et en conversations.

Par des humains pour des humains

L'une des nouveautés les plus enthousiasmantes de la journée fut le synthétiseur virtuel Circle, de chez Future Audio Workshop. Deux jeunes développeurs partis s'installer en Irlande, et qui ont choisi une approche rafraîchissante du développement de synthétiseurs logiciels: plutôt que de se focaliser sur l'originalité sonore ou sur les performances de calcul, ils se sont attachés à produire une interface utilisateur de très grande qualité. Exit les panneaux en bois, les vis en métal et les potars photo-réalistes parfaits pour des doigts que, souris oblige, on n'utilise pas. Ils ont développé une interface abstraite (qui n'est pas sans rappeler celle de Live), réellement étudiée pour le travail sur ordinateur.

Un exemple: chaque source de modulation a une petite lumière de sa propre couleur, qu'on peut tirer et déposer sur les petits réceptacles prévus à ce effet de n'importe quel autre contrôle de l'interface. Les modulations sont ainsi totalement flexibles, mais restent néanmoins parfaitement visibles. Malin!

Rendez-leur visite sur leur site, ou lisez cette critique de Circle par Create Digital Music.

De l'invention au produit

Clavia est une entreprise pour laquelle j'ai beaucoup de respect, et je garde un très bon contact avec ses ingénieurs depuis mon entretien chez eux en mars 2006 à Stockholm. Cette année encore, je suis allé leur rendre visite sur le stand tout rouge, et j'ai pu discuter avec Hans Nordélius, le fondateur de l'entreprise. Lui, pour le coup, c'est vraiment un vieux routier, dans le business depuis 1983, et lorsqu'il me parle de sa vision d'un produit, je me tais et j'écoute.

Hans est un ingénieur. C'est lui qui fut à l'origine du premier pad de batterie numérique, le Digital Percussion Plate 1, qui allait faire connaître Clavia et sa ligne de produits ddrum. Encore aujourd'hui, c'est lui qui élabore l'électronique des synthétiseurs Nord, et plus généralement, c'est lui qui a le dernier mot sur les décisions techniques, mais aussi commerciales.

Ce qui m'éclate vraiment, c'est que mes produits se vendent. Pour moi, le seul tampon qui valide la qualité d'un produit, c'est l'argent que le client sort dans le magasin. Je ne suis pas juste un inventeur ; un produit qui ne se vend pas, ça n'a rien de génial.

C'est en vertu de ce principe que, lorsque les "grabbar" de chez Clavia ont une idée de nouveau produit, ils la testent auprès de musiciens: sans réelle demande, pas question de se lancer. Chez Clavia, un produit, c'est plus qu'une simple réussite technique.

Un autre point important: Clavia ne transige pas avec la qualité. Inutile de lui demander pourquoi il ne fait pas produire ses instruments en Chine - la question l'énerve. Les instruments sont conçus et assemblés à Stockholm, et le public ne s'y trompe pas: un Nord, c'est cher, mais c'est du bon! L'augmentation stable des ventes de Clavia est un bel exemple qui montre que la qualité est une valeur qui marche sur le long terme. Et c'est aussi mon credo.

L'aventure

Enfin l'autre bonne surprise du salon, c'était de retrouver mon ancien collègue de l'Ircam, Pierre-Alexandre P., dans son propre stand! Lancée depuis peu, son entreprise Abeem Live Technologies développe Live Factory, un environnement modulaire principalement destiné à un usage scénique. Le produit est encore en plein développement, et il est bien trop tôt pour en parler. Ce qui m'a enthousiasmé, c'est le défi de la création d'entreprise. Allez, je vais même le concéder: j'étais presque un peu jaloux. Mais mon temps viendra. D'ici-là, je souhaite bonne chance à Pierre-Alexandre et à ses collègues, et j'espère que l'aventure continuera aussi longtemps et avec autant de succès que celle des facteurs d'instruments électroniques venus du Nord...

Critique: Multithreading

2008-03-11T21:23:00.009+01:00

Multithreading, version 0.9 (août 2007) par Bo I. Sandén, env. 300 pages, anglais, intégralement disponible en ligne.

Dans un billet précédent, j'avais évoqué mon manque d'assurance en matière d'architecture concurrente. Les mutex et autres sémaphores ne me font pas peur, mais je ne retrouve pas en matière de concurrence l'aisance que j'ai lorsque je fais de la conception statique.

Or il se trouve que l'Internet reflète bien mon malaise. Lorsqu'on cherche des textes sur le sujet, on trouve d'innombrables introductions à la programmation concurrente, avec leurs lot habituel de primitives à utiliser pour définir des sections critiques ou pour résoudre des problèmes d'accès en lecture-écriture à une ressource. Mais lorsqu'on veut monter d'un cran et parler architecture, c'est une autre paire de manches. Pour trouver des design patterns pour la conception concurrente, il faut se lever tôt.

Pour faire un parallèle avec l'architecture statique, c'est comme si les design patterns avaient disparu du Net, et que tout ce qu'on trouvait était des articles sur comment écrire des conteneurs efficaces, des pointeurs intelligents et des techniques de sérialisation. C'est bien pour les exercices à la fac, mais pour écrire le prochain OS grand public, c'est un peu maigre.

J'ai quand même fini par tomber sur Multithreading, de Bo I. Sandén. Là pour le coup, même si on n'échappe pas à l'introduction aux primitives de synchronisation en Ada et en Java, c'est vraiment un ouvrage sur l'architecture concurrente. L'auteur introduit une méthode de conception qu'il appelle Entity-Life Modeling, ou modélisation de la vie d'entités. Les entités en question sont les threads et les objets protégés (safe objects).

ELM bases multithreading on a simple, intuitive principle in the manner of object orientation where you model software classes and their relationships on domain objects and their relationships. ELM puts thread structuring on par with class structuring.

Si l'ouvrage introduit des design patterns pour la conception dynamique, on ne peut pas vraiment parler de catalogue: M. Sandén en présente deux. On peut être un peu déçu du faible nombre, mais il y a une astuce : ces deux solutions sont duales, c'est-à-dire que les deux peuvent être utilisées pour résoudre un même problème. Cette idée est si puissante qu'elle justifie à elle seule la lecture du livre. Si vous avez une solution, vous pourrez toujours examiner sa complémentaire pour savoir si celle-ci n'est pas plus efficace. Génial!

Je ne vais pas vous les présenter en détail, le livre est là pour cela, mais voici tout de même le principe de base:

Un thread utilisateur de ressources est un thread qui effectue l'ensemble d'un travail en acquérant successivement l'accès exclusif à des ressources partagées. Le thread représente donc une sorte de procédure complète. L'élément actif est le travail, alors que la ressource reste passive.
Un thread protecteur de ressource est un thread qui possède l'accès exclusif à une ressource, et qui reçoit un travail ponctuel à effectuer sur cette ressource par l'intermédiaire d'une file d'attente. Ici, le travail global n'est pas décrit par un seul thread, mais par la façon dont les threads sont connectés entre eux. Ce sont les ressources qui sont actives, et le travail est "transporté" passivement de l'une à l'autre.

Les deux solutions paraissent un peu évidentes énoncées comme ceci. Mais n'oublions pas que c'est aussi le cas des design patterns de la conception orientée objet. Personne ne s'est ému en lisant la description de Gamma et al. du singleton, mais tout le monde s'est félicité qu'il soit enfin clairement spécifié. M. Sandén, de ce point de vue, réussit donc son pari: ces deux modèles sont très clairement expliqués, et à la fin du livre, c'est sûr, on a compris.

Ce qui est plus gênant, c'est le trajet pour atteindre la fin du livre. En effet, sous prétexte de couvrir plusieurs problématiques différentes, l'auteur revient coup sur coup sur un certain nombre d'exemples qui arrivent un peu délavés à la dernière page. L'avantage, comme je l'ai dit, c'est qu'à la fin on a bien compris. L'inconvénient, c'est que la lecture n'est pas folichonne. Avec une écriture un peu moins verbeuse (note: je ne suis peut-être pas le plus apte à le critiquer là-dessus...) et un style un peu moins académique, il me semble que le sujet aurait pu être traité de manière plus efficace en moitié moins de pages.

Face à cette lourdeur, que les citations un peu geek et quelques traits d'humour ne font pas oublier, c'est tout un ensemble de petites notions pratiques et intéressantes qui passent un peu inaperçues, comme l'optimalité d'une solution ou les activités concurrentes, et qui font vraiment la saveur de l'ouvrage. Ajoutons à cela que le titre ultra-général promet plus que ce que n'apporte le contenu: le livre s'intitule Multithreading mais décrit en réalité une méthode bien précise, quoi que portant elle-aussi un nom bien vague, Entity-Life Modeling, qui n'englobe que deux patterns bien concrets dans lesquels les mots entity et life n'apparaissent pas. Dommage!

A noter quand même au tableau des bonnes choses: le chapitre 3 est un cours assez efficace sur la modélisation de machines à états. Avec le chapitre 4 qui introduit les deux patterns évoqués ci-dessus, ils contiennent à eux deux la moitié de la valeur du livre. Si (comme moi) vous avez des scrupules à tuer des arbres mais n'aimez pas lire sur écran, vous pouvez vous contenter d'imprimer ces deux chapitres-là.

Logiciel - Industrie ou Artisanat?

2008-02-24T16:30:00.001+01:00

Il n'est pas rare de rencontrer des développeurs qui insistent sur la qualité artisanale de leur travail. Au-delà du léger lustre de noblesse que fournit le mot à une activité souvent mal considérée, les similitudes entre le développement d'un logiciel et la production artisanale sont nombreuses.

Pour la couverture de leur livre The Pragmatic Programmer, Andrew Hunt et David Thomas ont choisi la photo d'un rabot dans un atelier poussiéreux, et ils ont raison lorsqu'ils comparent les attitudes des menuisiers et des développeurs par rapport à leurs outils respectifs.

Pourtant, j'ai toujours été gêné par ce mot d'artisanat. J'ai toujours trouvé qu'il manquait quelque chose, qu'il ne décrivait pas tout. D'ailleurs, je continue d'utiliser l'expression "industrie du logiciel" dans les pages de ce blog.

Alan Cooper semble avoir trouvé une distinction intéressante entre le développement de logiciels et l'artisanat. Alan Cooper est une figure de l'informatique, qui a plus d'une corde à son arc. On le nomme le Père du Visual Basic. Il est co-auteur de About Face, un livre sur l'interaction homme-machine, ou interaction design, qu'il convient de placer en bonne position sur sa liste de lecture.

Et puis il parle bien. Dans une longue présentation intitulée an Insurgency of Quality (une Insurrection de la Qualité) donnée lors du congrès Interactions'08, Cooper dresse un tableau de l'évolution du processus de développement, et en profite pour définir la nature du travail d'un développeur. Pour lui, il ne fait pas de doute que le développement d'un logiciel est plus proche de l'artisanat que de la production industrielle. Mais il évoque aussi les différences, et dégage ainsi les notions d'artisanat pré-industriel et post-industriel.

Cooper dresse d'abord la liste des similitudes entre l'artisanat pré-industriel et le développement. Chaque programme est un pièce unique, qui requiert toute l'attention du développeur. La production d'un logiciel ne peut pas changer d'échelle comme peut le faire la production d'un produit industriel, et passer d'une pièce unique à des millions d'unités. On ne peut pas réduire les coûts de manière substantielle si on souhaite maintenir la qualité du produit, et il n'y a pas non plus de "magic bullet", de méthode miracle pour décupler la qualité et la capacité de production sans contrepartie importante. Le développement est une activité extrêmement complexe, toute en nuances, et requiert des années de formation.

Mais l'artisanat pré-industriel, continue Cooper, était également caractérisé par une innovation technologique lente, et les outils évoluaient lentement. Ce n'est bien sûr par le cas du développement. Un logiciel, « c'est un ensemble de notions abstraites présentées avec des notations abstraites [...] C'est quelque chose d'invisible, d'intangible, d'impénétrable. »

Si l'activité de développement est donc proche de l'artisanat, elle est en revanche très éloignée de la production industrielle. Outre la grande différence de niveau de formation, il y a une différence plus fondamentale encore: un ouvrier travaille avec ses mains, un développeur travaille avec sa tête.

Avant de retrouver un missile scud dans mon salon avec des insultes écrites dessus au feutre, je précise tout de suite que je ne fais aucun jugement de valeur entre le travail manuel et le travail intellectuel. Les deux ont besoin l'un de l'autre, et le premier n'est pas moins noble que le second, tout comme la production n'est pas moins noble que la gestion. Si vous avez de tels missiles chez vous et que vous ne savez pas quoi en faire, ramenez-les à votre supermarché du coin pour être recyclés.

La combinaison de ces deux facteurs, niveau de formation et travail intellectuel, fait qu'un développeur est très souvent une personne autonome, qui a un sens très fort de ce qu'il a à faire, et qui est souvent, dixit Cooper, plus intelligent et plus éduqué que les gens qui sont censés le diriger. Enfin, « [sa] satisfaction professionnelle vient uniquement de la qualité de son produit, et pas de la performance de [son] employeur ».

Les vues de Cooper sur l'ouvrier sont peut-être un peu étriquées. Je veux croire qu'un travailleur manuel aussi éprouve de la satisfaction à bien faire son travail, et personne n'aime vraiment accomplir un travail de mauvaise qualité dont on ne puisse être fier. De même, les développeurs, qui sont plutôt des loups solitaires, aiment faire partie d'une équipe performante, et quoi qu'on en dise le salaire reste un facteur de satisfaction chez eux aussi.

Mais enfin il faut le reconnaître: l'épanouissement et la qualité du geste chez l'ouvrier qui serre des boulons à la chaîne, ou plutôt leur absence, a peu d'influence sur la qualité finale du produit. Par contre, mettez un cloporte ou un dépressif derrière un clavier, et votre logiciel prend lentement mais sûrement le chemin de l'enfer numérique. De même, mettez-moi avec un rabot dans les mains chez Bösendorfer, et voyez tous les pianistes du monde grincer des dents...

On peut dire du développeur qu'il est un artisan, mais comme tout ce qui touche au numérique, les notions et définitions ont évolué, et l'artisan numérique est plus le descendant de l'artisan manuel que son cousin. Les fondamentaux restent cependant les mêmes, et pour l'un comme pour l'autre, rien ne vaut le sentiment de satisfaction de laisser derrière soi un travail bien fait et une pièce unique.

Estimations et planning

2008-02-10T22:55:00.000+01:00

Pour un éditeur de logiciels, savoir prévoir avec un minimum de certitude la date de sortie d'une prochaine version ou mise à jour présente un intérêt sur le plan commercial aussi bien que financier. Toute entreprise a un budget à gérer, et il est vital d'avoir un bon aperçu des moments où l'on peut attendre des rentrées d'argent.

En termes de développement d'un produit logiciel, cela revient à dresser la liste des fonctionnalités à implémenter ou à améliorer, à estimer le temps de travail nécessaire pour chacune d'elles et à faire le total du tout pour obtenir une date de sortie possible.

Notez bien: il y a un piège dans le choix du mot "développer". Pour moi, cela comprend les tests et le débogage, ces deux phases-là prenant la plupart du temps plus de temps que l'implémentation elle-même. Mais oui, Madame!

Estimations et planning chez Ableton

Au Royaume d'Ableton, chaque Maître Développeur doit estimer lui-même le temps qu'il lui faut pour une fonctionnalité donnée. A partir de ces estimations, un planning de sortie est établi, qui doit être validé par le Grand Argentier, qui sait combien de temps le Royaume peut tenir sur ses réserves accumulées lors de la dernière sortie. Bien sûr, comme avec tout projet logiciel, il y a des retards. Le génie des Gardiens du Planning est de considérer ces retards comme des faits (et non comme des erreurs et un coupable à écarteler sur la place publique) et de décider s'il faut repousser la date de sortie, ou s'il vaut mieux laisser tomber la fonctionnalité, cette dernière décision étant toujours prise avec l'accord du Conseil Suprême des Spécifications.

Le développeur découpe donc sa fonctionnalité en sous-tâches, plus faciles à estimer, chacune représentant moins de 16 heures de travail.

Je prends un exemple: avec Live 7, nous avons introduit de nombreux instruments et extensions sous forme de contenu, et chacun vient avec son numéro de série, si bien qu'un utilisateur qui achète Ableton Suite se retrouve avec 9 numéros de série. Avec la version 6 il aurait fallu les entrer les uns après les autres pour tout débloquer ; Live 7 contacte Ableton.com lorsqu'on entre le premier numéro, reçoit automatiquement tous les autres, et propose à l'utilisateur de tout débloquer d'un coup de cuiller à pot. En interne, nous avons nommé cette fonctionnalité UnlockLicense, car elle permet de débloquer toute une licence grâce à un seul numéro de série.

Peut-on en estimer correctement le temps nécessaire pour la tâche "Implémenter UnlockLicense"? Un peu de code réseau, quelques modifications de code de gestion des licences, une ou deux fenêtres de dialogue, allez... hmmm, on va dire 20 heures, 22 à tout casser. Il y en a un peu plus, je vous le mets quand même?

Bien sûr, une telle estimation ne vaut rien. Il faut avoir déjà réfléchi au problème pour savoir exactement ce qu'il y a à faire:

Création d'une requête HTTP
Connexion synchrone avec le serveur et réception du résultat
Décodage du résultat
Traitement de chacun des 7 cas d'erreur possibles
etc...

Voilà des tâches plus simples à estimer. "Création d'une requête HTTP": 2 heures, refactorings et tests unitaires compris.

Pour des raisons de comptabilité, chaque développeur doit également enregistrer combien de temps il passe sur chaque tâche, les tâches appartenant à des projets différents qui doivent être comptabilisés différemment. En plus, il faut pouvoir connaître l'état d'avancement d'une fonctionnalité. Nous voilà donc avec deux données à récolter pour chaque tâche: 1) une estimation du temps nécessaire, et 2) une mesure du temps réellement passé.

Nous utilisons pour cela un petit outil interne, la Todo List, qui permet d'entrer les tâches et de donner une estimation pour chacune d'elle. L'outil permet aussi de chronométrer le temps passé à travailler sur chaque tâche.

A la recherche du temps perdu

Je décidai de m'intéresser au sujet après avoir lu plusieurs articles là-dessus. Je commençai à dresser des listes de tâches et à enregistrer le temps passé sur chacune d'elle, puis je comparai le résultat à mon estimation initiale - en général, je calculais un total en heures que je divisais par 8 pour obtenir une estimation en jours.

L'un de mes premiers constats fut que je ne travaillais pas 8 heures par jour. Surprise! Bien que je passais 8 heures au bureau, mon temps de travail effectif était plutôt, coïncidence étrange, de 5 heures. Le reste: réunions, cafés, furetage sur Internet, administration, etc. il est vrai que si je travaille en général plutôt bien, je travaille lentement, et il y a sans doute beaucoup de gens qui tournent plutôt autour 6 heures par jour (pour 8 heures de présence), mais personne ne passe 100% de son temps au bureau à produire.

Une fois cet ajustement fait, je me retrouvai confronté à un autre problème: celui de tout comptabiliser... et aussi le reste! Ainsi, la durée d'une tâche de développement peut comprendre, en plus du temps de codage: spécification, prototypage, débogage, tests, mais aussi réunions, vacances, pannes informatiques, grèves, arrêts maladie, etc. Les premiers rallongent le temps qu'il faut pour terminer une tâche, les seconds diminuent le temps qu'on peut y passer sur une période de temps donnée.

Ces paramètres désormais pris en compte, il ne restait plus qu'une chose à peaufiner: la qualité de l'estimation elle-même. Lorsque j'ai commencé à utiliser la Todo List chez Ableton, le Maître du Planning m'a expliqué qu'il fallait mettre à jour l'estimation si le temps passé sur une tâche dépassait la première estimation. Ce que je fis pendant longtemps. Sauf que cette approche à un problème: si elle permet de corriger la date prévue de fin d'implémentation, elle ne permet pas de mesurer la qualité de l'estimation, puisque le temps estimé finit toujours par être très proche du temps passé.

Or ce qui intéresse votre serviteur, c'est d'améliorer ces estimations. J'ai donc eu une autre idée: lorsqu'une tâche vient tout juste de dépasser le temps estimé, je crée désormais une nouvelle tâche, avec le même nom, mais avec un petit numéro entre parenthèses. Par exemple:

Connexion synchrone... [Estimé: 3 heures, passé: 3h20]
Connexion synchrone... (2) [Estimé: 2 heures, passé: 2 heures]

Ayant sottement (mais humainement) oublié la version Mac OS de cette partie du code, hop! voilà 2 heures en plus à glisser dans ma liste. Avec cette méthode, on voit très bien ce qui s'est passé: en tout, la tâche à duré 5h20 alors que mon estimation d'origine était de 3 heures, mais l'estimation finale est correcte à 20 minutes près. Comme les deux tâches appartiennent au même projet, le résultat final reste bon.

Ainsi, lorsqu'une fonctionnalité est terminée, je peux revenir sur mes enregistrements et analyser la qualité de mes estimations. Les dernières mesures ont montré que je suis un indécrottable optimiste, car mes estimations ne représentent en moyenne que 80% du temps réel. Comme au lycée: sérieux, mais peut mieux faire.

Spolsky Based Scheduling

La source la plus intéressante à mon sens sur l'estimation du temps, c'est Joel Spolsky. Dans son produit phare, FogBugz, un outil de gestion de projets, il a poussé l'estimation du temps plus loin: plutôt que de produire une date de sortie figée, FogBugz prend en compte les erreurs d'estimations de chacun pour produire une courbe indiquant la probabilité de sortir le logiciel avant tel ou telle date. Il appelle sa méthode Evidence Based Scheduling, soit pour Molière: la gestion du temps basée sur les faits.

Voici trois de ses articles sur le thème de l'estimation. Ils sont tous intéressants, y compris le premier, malgré le petit encart qui indique que l'article est obsolète.

Bonne lecture!

La Boîte à Xecrets

2008-01-30T21:46:00.000+01:00

La multiplication des PIN

Au commencement, il y avait la Terre, les hommes, le ciel, la lumière, l'air, l'eau et mon ordinateur, doté d'un mot de passe. C'était un temps heureux, où mon cerveau était libre de penser à ce qui lui plaisait.

Puis, Wanadoo arriva au village, et proposa l'accès à Internet, avec identifiant et mot de passe pour la connexion, et adresse e-mail et mot de passe pour la boîte mail. Rien d'insurmontable pour ma mémoire qui, à l'époque, semblait n'avoir aucune limite.

Puis soudain, je créai une autre adresse mail, chez iFrance. Identifiant plus mot de passe.

Puis peu après, voilà qu'IBM me demande de me choisir un nouvel identifiant et un encore un mot de passe. Puis c'est au tour de Sun. Puis Yahoo. Puis feu Be. Puis Yahoo!. Puis... ah! je ne me souviens plus. Login et mot de passe. Username and password.

Puis mes ordinateurs se multiplièrent: chez moi, en stage, à la fac (deux comptes!), chez mon père. Login, login, login. Mot de passe.

Puis à 18 ans je lus "Applied Cryptography" de Bruce Schneier (le livre que la NSA aurait préféré ne pas voir publier...), et décidai que la crypto et la sécurité, c'était trop grave vital, et augmentai la qualité de mes mots de passe. La seule pensée de réutiliser le même mot de passe pour Blogonautes (qui stocke les mots de passe en clair!) et mon compte RueDuCommerce, où j'ai des informations de carte bancaire, devenait insoutenable.

Les octets commencèrent à tourbillonner dans ma tête. Je me mélangeais les pinceaux: sur Amazon.fr, c'était "lk259mIcS" ou "!bh92ls"? Ni l'un, ni l'autre: c'était Ikea.se et la Fnac.com, respectivement.

La situation devenait intenable. Je commençais à noter toutes mes infos d'accès dans des fichiers texte que je stockais sur des partitions cryptées. Encore des mots de passe! Puis en passant sous Linux (hop! deux comptes!), je dus changer d'outil de crypto, et tout recommencer. Et rebellotte en revenant sous Windows. Argh!!!

La boîte de Pandore

En Novembre dernier, ma vie reprit soudain le chemin de la lumière: mon frère, Svante Seleborg, créateur d'AxCrypt et en visite à Berlin, m'annonça qu'il venait de lancer un service Internet: Xecrets.

Xecrets, c'est une boîte à secrets virtuelle. Une adresse mail et un solide mot de passe (sic!) plus tard, j'avais un endroit où noter toutes mes informations de comptes sur tous les stupides services en ligne de la planète. Je peux y accéder partout où j'ai accès à Internet, ce qui est plus souvent garanti qu'avec n'importe quelle autre solution que j'utilisais avant.

Vous me direz, des services comme cela, il en existe déjà. Oui! Mais l'avantage de celui-là, outre le fait que c'est le service de mon frère, que j'ai pu en discuter avec lui, que je suis l'un des premiers utilisateurs (grisant!) et qu'il a lui-même fait ses preuves en matière de sécurité avec l'excellent AxCrypt... outre cela, donc: j'ai eu le droit à une visite guidée du code source!

Je sais exactement comment le système fonctionne! Toutes les données sont stockées sous forme cryptée. Il est impossible à quelqu'un qui s'introduit dans le serveur d'Axantum d'y lire mes secrets, qui sont protégés par une clef de session générée à chaque fois, continuellement resalée avec une nouvelle valeur, et cryptée avec mon mot de passe. Toute la communication avec mon Renard-qui-prend-feu passe par SSL. La session reste ouverte une heure, no questions asked, et pas question de "se souvenir de moi sur cette machine".

L'utilisation est simplissime. La page d'accueil ressemble un peu à Google: une champ de recherche, trois boutons, puis la liste des mes entrées et en voiture Simone! Pour chaque entrée, je peux inscrire un titre, ainsi que les infos importantes, comme l'adresse Internet du service, mon nom d'utilisateur, etc: c'est un champ libre, j'y mets donc ce que je veux.

Le mot de passe, lui, bénéficie d'un champ spécial, la précieuse info n'apparaissant que lorsqu'on clique dedans, le temps de le copier dans le presse-papier pour le coller sur la page d'accueil de GMail. Même si quelqu'un regarde par-dessus mon épaule, il lui est impossible de mémoriser le mot de passe, d'autant plus que je m'en donne à cœur joie pour en trouver des bétons. 42djf0w3j#2S(D)A3k2lj5d_9s. Na!

Xecrets est en phase beta. Je fais du lobbying intense pour un générateur de mots de passe. C'est plus facile de faire du lobbying quand on a le numéro de téléphone du développeur en chef!

Mais dans l'ensemble, tout fonctionne, et je ne m'en passe plus. Et s'il y a un web-service indispensable en ces temps frénétiques où même EasyJet me somme de créer un compte, c'est bien Xecrets...

L'Informatique Sentimentale

2008-01-21T21:17:00.001+01:00

La clef du succès

Le plus important pour le succès d'un outil logiciel, c'est d'avoir une bonne place dans le cœur de l'utilisateur. Tous les autres critères de qualité y sont subordonnés: stabilité, économie de ressources, prix, élégance de l'interface, sécurité, etc. Tout finit au même endroit: l'affectif. Je prends toujours du plaisir à utiliser les outils que j'aime, même lorsqu'ils ne sont pas parfaits.

Avant de continuer, voici la liste des logiciels que j'utilise avec plaisir:
- Mozilla Firefox
- Microsoft Excel
- Microsoft Visual C#
- Google Maps
- Tortoise SVN
- 7-Zip
- La calculatrice Windows

Pourquoi est-ce que j'aime utiliser ces outils et pourquoi suis-je mal à l'aise avec d'autres? La réponse est bien sûr liée à mon ressenti.

Raison et sentiments

Si je sais que je peux cliquer partout sans faire planter l'outil et sans perdre de données, je me sentirai en confiance. Si je sais que je peux réparer n'importe quelle boulette en cliquant sur "Undo", je n'aurais plus peur de faire des boulettes! Si je sais que l'outil ne me piégera jamais avec une fenêtre que je ne peux pas faire disparaître avec "Annuler", cela m'encouragera à explorer les fonctionnalités.

Si en plus j'atteins des résultats probants rapidement, et que j'apprends facilement à m'en servir, alors c'est l'extase total, et j'éprouverai un profond sentiment de satisfaction, et après une bonne journée de travail sur un tel outil, je rentrerai serein à la maison, je dormirai bien, et je ne me réveillerai pas à 5h du matin tout angoissé et en éprouvant le besoin d'écrire un article mortifère sur le développement logiciel chez Sagem.

Comme si les pointeurs et les threads n'étaient pas assez compliqués comme ça, voilà que je viens vous expliquer la bouche en fleur qu'en plus il faut faire attention à des notions abstraites comme la confiance, la peur, l'encouragement ou la satisfaction. Diable!

C'est une affaire d'autant plus délicate que qu'un simple détail en apparence bénin peut tout déséquilibrer d'un coup. Vous est-il arrivé de formuler un message d'erreur ou d'information en utilisant "s'il vous plaît"? Comme par exemple: "Veuillez insérer le CD-ROM d'installation, s'il vous plaît"?

Perdu!

Alors que vous pensiez gagner des points en politesse, vous en perdez ailleurs. Cette locution, en effet, qui intervient essentiellement dans des échanges profondément humains, apporte une teinte humaine au message. Or un outil n'est pas un humain ; les humains sont chouettes, certes, mais ils sont aussi par nature complexes, imprévisibles et font des choix par eux-même, les bougres! On a vite fait de vexer un humain, même sans le vouloir, et alors bonne chance pour lui faire copier 650Mo de données d'un disque à l'autre.

De la part d'un outil, c'est tout le contraire qu'on attend. De la part d'un outil, fiable est plus important que poli. Notez d'ailleurs que "s'il vous plaît" n'apparaît pas souvent dans les outils que j'ai cités plus haut, ce qui n'empêche pas certains d'être des best-sellers.

La petite oreille

J'accorde donc une place très importante au ressenti lorsque je crée moi-même un outil. Les meilleurs développeurs savent prendre suffisamment de recul par rapport à leur travail pour écouter leur propre ressenti et le prendre en compte.

De même, ils respectent le ressenti des autres. Combien de fois ai-je tenté de me justifier lorsque quelqu'un a émis un commentaire qui relevait uniquement du perceptif, comme pas exemple "pas très intuitif" ou "je n'ose pas cliquer là"? Aucune dose d'explication n'a jamais effacé le fait que ce fut la première impression de cet utilisateur, et il m'a fallu longtemps pour comprendre qu'il valait mieux la respecter et en prendre note pour améliorer celle des suivants. Souvenez-vous, la première impression compte!

"Pour connaître l'homme, il suffit de s'étudier soi-même"
-Stendhal

Henri Beyle, dit Stendhal, était sans conteste un très fin connaisseur de l'âme humaine. Cette petite phrase, en plus de faire très chic sur un blog, nous apprend que notre ressenti ressemble probablement très fort à celui de nos utilisateurs. C'est un peu comme de travailler avec un testeur redoutable, gratuit et disponible sur-le-champ, et qui en plus a les mêmes MP3 que vous. Le rêve!

Parvenir à percevoir correctement son ressenti n'est bien sûr pas chose facile. Mais je crois que les développeurs sont des gens intuitifs, et très souvent leur intuition, ou leur "petite voix intérieure", fonctionne bien, beaucoup mieux souvent que la "petite oreille intérieure" qui devrait l'écouter. Autrement dit, l'information est souvent là, mais rarement captée correctement.

Mais ce n'est pas tout, car "petite voix" se perd si facilement dans un brouhaha de préjugés et de certitudes! L'arrogance, l'excès de confiance en soi, la passion, l'amour propre sont autant de de gênes à cette perception. Difficile de laisser de côté les heures passées à concevoir une belle fenêtre de dialogue lorsqu'au plus profond de soi, on sent bien qu'elle n'est pas très claire. Il faut alors savoir mettre fin à la phase de quasi-euphorie qui suit la création pour prendre du recul et réévaluer objectivement le résultat.

A titre d'exercice, la prochaine fois que vous créez quelque chose qui vous plaît (une fenêtre, un algorithme, ou même une chanson ou un article sur votre blog), prenez conscience de cette euphorie durant laquelle vous trouvez votre création parfaite, et demandez-vous si vous pourriez, dans la seconde, accepter que le résultat n'est pas au top de ce que vous êtes en mesure d'accomplir. Lorsque ce sera effectivement le cas, vous serez armé pour passer outre le désagrément et produire quelque chose de mieux encore.

Conclusion

Le succès de votre logiciel sera directement lié à la place qu'il occupera dans le cœur des gens et à la perception qu'ils en ont. Pour produire l'outil parfait, en plus des qualités tangibles qu'on attend habituellement, vous devez faire attention au ressenti de l'utilisateur. Ce ressenti, vous pouvez en avoir une idée en écoutant le vôtre; et si quelqu'un vous fait part du sien, ne le rejetez pas! Vous serez alors en mesure de produire un outil qui mette l'utilisateur en confiance, qui l'encourage à en explorer les possibilités et qui le récompense en l'aidant à obtenir des résultats vite et bien. Et vous aussi, vous en dormirez mieux.

Le Marteau

2007-12-02T11:00:00.000+01:00

Low-tech

Je n'ai jamais entendu personne se plaindre de ce qu'un marteau n'est qu'un marteau.

Jamais personne ne m'a dit qu'il voudrait un marteau avec, mettons, des têtes interchangeables, ou avec plusieurs grips de toutes les couleurs pour pouvoir en changer selon l'humeur et la saison, ou encore avec un réglage du rapport poids/dureté de l'acier, ou avec un contre-poids pour soulager ce tennis-elbow qu'on traîne depuis plusieurs semaines déjà. Un correcteur gyroscopique et détection automatique d'un pouce sur la trajectoire? Jamais entendu parler.

Si je regarde le marteau que j'ai chez moi, je compte en tout et pour tout trois fonctionnalités:

Une table (la partie qui percute) en acier très dur qui ne se déforme pas au contact du clou,
un arrache-clou de l'autre côté de la tête, que j'utilise presque aussi souvent que la table (mais c'est personnel),
un grip sur le manche pour que le marteau ne me glisse pas des mains.

Il possède en outre quelques caractéristiques intéressantes: il est quasiment incassable, ne consomme aucune énergie et ne nécessite ni manuel d'utilisation, ni maintenance. Il fonctionne même les soirs de victoire en coupe du monde.

Il existe bien sûr les pistolets à clous qui permettent certes de gagner du temps, mais qui sacrifient pour cela plusieurs des qualités ci-dessus. Moi, pour moins de 15€ j'ai un outil intuitif, robuste, fiable et qui me durera probablement toute la vie.

Un outil, un problème

Si les brevets avaient existé à l'époque, et si le gars qui a inventé le marteau en avait déposé un, ses descendants pourraient s'acheter l'Amérique du Nord lors de leur shopping du samedi. Il existe au moins autant de marteaux que de maisons. Mon père en a un tiroir entier à lui tout seul. Comment expliquer ce succès?

Parce que le marteau résout un seul problème: planter des clous. Certes, c'est un problème répandu. Plus répandu, en tout cas, que "accélérer des particules" (c'est un exemple). Mais tout de même: pour que dans chaque maison il y ait un marteau, encore faut-il que l'outil soit au point. Et c'est le cas! Avec un seul problème à résoudre, pas étonnant qu'on fasse difficilement mieux.

Lorsqu'on n'a qu'un seul but, il devient possible de l'atteindre à la perfection. Prenez le violon. Instrument complexe, objet beau et élégant, le violon ne fut jamais aussi bon que... sous Antonio Stradivari, au début du XVIIIème siècle! Je ne blague, personne n'a jamais fabriqué de meilleur violon que cet homme-là. Un beau son, projeté loin, voilà les critères fondamentaux du violon - un soliste aujourd'hui doit pouvoir jouer dans des salles de plus de 2000 personnes. Les modernes qui ont essayé d'utiliser les moyens sophistiqués que la science a mis à leur disposition ont, au mieux, réussi à produire des violons qui sonnent plus fort, mais ceux-ci ont, à ma connaissance, systématiquement été rejetés par les artistes parce que produisant un son moins intéressant. L'objectif était limité: produire un violon. Et c'est déjà au début du XVIIIème siècle, moins de deux cent ans après la naissance du violon, que le résultat parfait fut obtenu.

Taxe fonctionnelle

Un outil, un problème : illustration. AxCrypt fait une seule chose: crypter des documents. Parce qu'il ne fait que cela, il le fait à merveille. Dans la plupart des cas, une fois le document crypté, la seule étape supplémentaire nécessaire pour ouvrir un fichier et travailler dessus est d'entrer un mot de passe - au clic près! Cette étape est plus ou moins imposée par le domaine d'application, mais c'est aussi la seule chose qu'AxCrypt vous demande en plus. La taxe fonctionnelle de l'outil en lui-même est nulle.

Prenons le cas inverse: le téléphone mobile. C'est sans doute pour beaucoup un appareil de cœur, mais voilà bien un outil qui tente de résoudre plusieurs problèmes à la fois: la téléphonie, l'envoi de messages texte, la tenue d'un répertoire et son accès, les jeux vidéo, la navigation GPS, la photographie, la musique. Du coup, rien n'est fait jusqu'au bout. Mettez-moi dans une Fnac, et je peux, pour chaque fonction de votre portable que vous m'énumèrerez, trouver en moins de cinq minutes un outil qui le fera mieux, avec une ergonomie adaptée à sa fonction.

A chaque fois qu'un développeur ajoute une fonctionnalité à son outil, il doit penser à la taxe fonctionnelle. Cette taxe sera nulle si la fonctionnalité ne gêne pas lorsqu'elle n'est pas utilisée, et si son utilisation ne gêne pas les autres fonctionnalités. L'interface de cette fonctionnalité doit être suffisamment soignée pour ne pas obliger l'utilisateur à consulter la documentation.

Ainsi, lorsque je veux composer un SMS sur mon rasoir, je dois systématiquement choisir entre SMS, MMS, email ou message vocal. Ce "clic" supplémentaire est la taxe que je paye parce que quelqu'un un jour a décidé qu'un téléphone devait pouvoir envoyer plusieurs types de messages et que quelqu'un d'autre n'a pas su comment l'implémenter.

I had a dream

J'espère voir un jour de mes propres yeux l'âge de raison de l'industrie informatique, l'époque où nous limiterons spontanément et naturellement le périmètre fonctionnel de nos applications parce que ce sera la chose la plus raisonnable et la plus sensible à faire. Une époque où chaque outil pourra être décrit en une phrase unique, par la présentation de l'unique problème qu'il tente de résoudre. Où l'utilisation de chaque outil sera si intuitive qu'elle sera à la portée de n'importe qui ayant à s'en servir. Où la taxe d'utilisation de l'informatique sera abolie.

Alors, je pourrai apprendre enfin à me servir correctement de mon marteau.

Saine concurrence

2007-11-20T23:19:00.001+01:00

J'avoue humblement mon manque d'expérience en matière de programmation concurrente.

Bien sûr, je connais les notions de thread, de sémaphore, de mutex, etc. Je les ai utilisées plus d'une fois. J'ai même travaillé sur des problèmes de communications inter-threads et inter-processus assez épineux lors de mon passage chez eNetshare. En fait, je pense que j'en sais autant (ou plutôt aussi peu) sur la programmation concurrente que la plupart des développeurs non experts en la matière.

Mais cela ne m'empêche pas de me sentir peu à l'aise lorsqu'il s'agit de concevoir une architecture complexe comme celle sur laquelle je travaille à mes heures perdues (je n'en dis pas plus aujourd'hui, car ce projet mérite plusieurs articles à lui seul), qui implique l'exécution en temps-réel d'un langage interprété et un d'un graphe de traitements audio.

Herb Sutter, un grand personnage dans la communauté C++ et certainement quelqu'un dont le discours mérite d'être écouté, expliquait déjà en mars 2005 pourquoi la programmation concurrente est à prendre au sérieux: le déjeuner à l'œil, c'est fini. Le temps joyeux où la vitesse d'exécution des programmes bénéficiait gratuitement de l'accélération des cadences des processeurs tend vers sa fin, et les gains de performance devront à l'avenir être recherchés ailleurs, et notamment dans la concurrence. Mieux encore que les cartes graphiques ultra-puissantes d'aujourd'hui, la Playstation 3 en est une belle illustration: elle tire ses performances exceptionnelles de son architecture Cell, avec 7 processeurs spécialisés travaillant en parallèle pour les divers types de calculs nécessaires.

Toutes ces belles raisons m'ont poussé à rechercher de la documentation sur la programmation concurrente avancée sur Internet ou sous forme de livre. Ce qu'on y trouve est étonnamment pauvre. Les introductions à la programmation concurrente sont aussi nombreuses que les musiciens dans le métro parisien, et de qualité analogue. Une fois qu'on a compris le sémaphore, on trouve quelques articles intéressants sur la programmation lock-free, mais le traitement de l'architecture concurrente laisse singulièrement à désirer.

Si la programmation multithread mérite le respect, elle ne doit pas provoquer la crainte.

Cependant, je ne désespère pas. Je viens de tomber sur l'ouvrage de mon compatriote suédois le professeur Bo I. Sandén, Multithreading, un livre abordant la conception d'applications concurrentes entièrement disponible en ligne (c'est une version beta... décidément, un doux vent de folie souffle sur ces universitaires qui font de l'informatique). Le dr Sandén propose une approche pratique et claire de la programmation multithread, baptisée Entity-Life Modelling, ou "modélisation de la vie d'entités".

Je n'en suis qu'au seconde chapitre, il est donc bien trop tôt pour me prononcer sur la qualité de l'ouvrage. L'approche pratique me plait, et j'espère que je trouverai des réponses satisfaisantes à mes questions dans les chapitres à venir.

Affaire à suivre.

[Mise à jour du 11/03: lisez ma critique sur cet ouvrage]

Colportage virtuel

2007-06-16T18:10:00.000+02:00

L'autre jour au bureau, je codais tranquillement quelque fonction lorsqu'un collègue vint m'interrompre pour me poser une question. Cela arrive.

Nous examinions donc son problème, lorsque soudain Thunderbird me fit savoir que j'avais un nouveau message. Curieux, forcément, j'ouvre ledit message, auquel est attaché un PDF. Comme il semble que la partie intéressante soit dans le PDF, je l'ouvre à son tour.

Et c'est alors qu'Acrobat Reader me demande si je souhaite faire une mise à jour.

Un petit instant je vous prie. Au moment où le gymnaste du document électronique m'affiche son message, voici l'état, si je puis dire, de ma pile d'appel:

. Coder une fonction
. . Répondre à une question de mon collègue
. . . Lire un mail
. . . . Lire un document
. . . . . Décider si je dois mettre à jour Acrobat Reader

Passons sur mon propre manque de politesse lorsque je lis mes mails alors qu'un collègue est avec moi, ce n'est pas très courtois de ma part, mais ce n'est pas non plus l'objet de cet article.

Le problème est que j'ai déjà interrompu trois activités, et Acrobat me demande encore si, par hasard, cela m'intéresserait de mettre à jour mon afficheur de PDF. Mon cerveau est déjà en train de jongler avec plus de boules que de raison, et j'ai d'ailleurs à ce moment là déjà laissé tomber deux variables locales, et il faut en plus que je décide si je souhaite installer une nouvelle version de Reader.

Point de vue du développeur

Les mises à jour automatiques sont la meilleure invention depuis le ciseau à couper le fil à couper le beurre. Elles me permettent à moi, créateur, de faire évoluer en permanence mon logiciel sur les ordinateurs de mes utilisateurs! Non seulement ils reçoivent ainsi très vite les derniers gadgets que j'y ai incorporés, mais je peux aussi corriger mes bugs les uns après les autres, et je suis sûr que les répercussions ne tardent pas chez mes fidèles utilisateurs.

Mais il y a mieux! Les mises à jour automatiques me permettent de programmer des mécanismes métaphysiques complètement glucoses par lesquels mon programme fork() avec un outil associé qui télécharge la mise et jour et applique un patch sur l'exécutable principal et ensuite re-fork() avec le programme et hop! ni vu ni connu j'ai modifié en un tournemain l'application et il avait raison l'autre de dire qu'en programmation on peut résoudre tous les problèmes avec une indirection supplémentaire et si De Vinci avait eu les pointeurs et le web, l'humanité serait aujourd'hui bien supérieure à elle-même (fork() ?) et la guerre en Irak n'aurait jamais eu lieu.

Car, enfin quoi, quel service je rends là à mes utilisateurs! Il est évident et logique, au nom de la plus pure pensée cartésienne, que toute nouvelle version de mon logiciel que je finis est meilleure que la précédente. En fait, les mots évolution et amélioration sont parfaitement synonymes, et tiens d'ailleurs je pourrais presque envoyer un courrier à l'Académie Française pour leur demander d'en supprimer un, au hasard, allez! évolution. J'espère que leur Acrobat Reader est à jour...

Point de vue de l'utilisateur

A la maison, j'utilise Gentoo, la distribution linux do-it-yourself par excellence, où on passe plus de temps à compiler les applications qu'à les utiliser, surtout sur mon processeur vieillissant. Laissez-moi vous dire qu'en matière de mise à jours métaphysiques, Gentoo c'est le top du top. Du pur Aristote. Tiens, prenez le compilateur GCC par exemple. Vous avez bien sûr déjà un GCC installé, sinon on retombe sur le problème de la poule et l'oeuf, et à ce sujet je vous invite à lire le court texte intitulé De l'impossibilité d'établir une carte de l'empire à l'échelle 1/1 par Umberto Eco, très édifiant sur ce types de paradoxes.

Or, donc, vous avez déjà votre GCC. Le processus est le suivant, plus ou moins automatique selon les goûts et les distributions :

Vous téléchargez le code source de la nouvelle version et vous libérez, comme autant de chrysalides sortant d'un même cocon taregézède, tous les fichiers sources.
Vous lancez la compilation, et profitez d'avoir enfin un moment pour entamer Guerre et Paix. Note: c'est votre GCC existant qui compile son successeur - quel sens du devoir!
Dans la scène finale du film Alien 4, le monstre nouveau-né rend un émouvant hommage à sa mère en la trucidant sur place. Eh bien là c'est pareil, le GCC nouveau vampirise purement et simplement son géniteur en prenant sa place, et se recompile lui-même. N'essayez pas d'expliquer cela à un prêtre, point de vue hérésie on est limite.
Pour ceux qui veulent basculer complètement du côté obscur, le pied-de-nez ultime à la théorie de la Genèse consiste à recompiler, avec son nouveau GCC, son noyau Linux. Même Lucifer ne fut jamais aussi fort, et pourtant Dieu sait qu'il essaya.

Ça, c'est le cas extrême. Pour la plupart des applications, le processus est plus simple, et bien plus acceptable déontologiquement. Sur Gentoo, vous utilisez portage pour faire cela, et la plupart du temps, cela fonctionne très bien et est très simple.

Jusqu'au jour où ça ne fonctionne plus. Il y a quelques semaines, j'ai fait une mise à jour complète de mon système. N'étant pas de ceux qui ont froid aux yeux, et ayant confié tous les fichiers de configuration de mon système à Subversion, le banquier Suisse du fichier ASCII, j'ai lancé la commande fatidique pour tout mettre à jour.

Master: Boatswain.
Boatswain: Here Master: what cheer?
Master: Good: speek to th' mariners: fall to't, yarely, or we run ourselves aground, bestir, bestir.
Exit. Enter Mariners.
Boatswain: Heigh my hearts, cheerly, cheerly my hearts: yare, yare: take in the top sail: tend to th' Master's whistle: blow till thou burst thy wind, if room enough!

William Shakespeare - The Tempest

Il m'a fallu trois jours pour m'en sortir.

15 logiciels ont purement et simplement refusé de compiler. Trois autres bloquaient tout le processus parce que leurs versions n'étaient pas compatible avec je-ne-sais quel autre logiciel présent sur La Longue Liste. Des changements significatifs dans certains sous-systèmes importants ont perturbé certaines fonctionnalités ésotériques, comme par exemple l'utilisation d'une clef USB, jusqu'à ce que je trouve par accident la bonne configuration pour tout remettre en place. Mon appareil photo n'est plus reconnu. Et je vous épargne l'histoire du Wifi.

C'est peut-être pour cela que je repense avec une certaine nostalgie à la glorieuse époque de l'université, quand TeX était mon outil principal. Un vrai bonheur, TeX est presque complètement libéré de la notion de mise à jour, comme l'explique Wikipedia:

The current version of TeX is 3.141592; it was last updated in December 2002. The design has been frozen after version 3.0, and no new feature or fundamental change will be added after that, so that all newer versions shall contain only bug fixes. Even though Donald Knuth himself has suggested a few areas in which TeX could have been improved, he indicated that he firmly believes that having an unchanged system that will produce the same output now and in the future is more important than introducing new features.

En termes de développement logiciel, si vous ne savez pas à quel saint vous vouer, Donald Knuth est un bon candidat - un peu excentrique peut-être, mais ça ne fait pas de mal. Avec TeX donc, pas de surprise, pas d'incompatibilité, pas de changement inopiné de comportement, on installe TeX et c'est un peu comme un mariage: c'est pour la vie. Microsoft Word, à côté, fait un peu volage.

Point de vue de l'humain

Et si votre boulanger vous disait, en vous tendant la baguette, avec le petit regard en coin de celui qui vous refile un bon tuyau: "Vous devriez attendre demain, le pain sera meilleur"?

Hein? Pourquoi? Le pain n'est pas bon aujourd'hui? Comment sera-t-il demain? Meilleur, ça veut dire quoi? La qualité sera meilleure? Ou est-ce parce que demain il y aura du sel de Guérande dedans? Et qu'est-ce que je fais en attendant? Pas de baguette aujourd'hui?

De la part d'un anti-virus, je peux le comprendre. Mais de la part de, mettons, TortoiseSVN, qui pourtant n'a vraiment rien à se reprocher, où même d'Acrobat Reader, je ne comprends pas cette insistance à vouloir me refiler une mise à jour dès qu'elle sort. Ça veut dire quoi? Trois sentiments se chamaillent alors dans mon esprit.

Le logiciel est bogué, et la mise à jour va régler le problème. Soit! S'il est si bogué au point que tous les utilisateurs doivent le mettre à jour, ne faudrait il pas mettre en place une phase de bêta-tests? Et qu'est-ce qui me dit que la mise à jour, du coup, ne contient pas aussi son lot de nouveau bugs?
La mise à jour va m'apporter une nouvelle fonctionnalité qui va me rendre heureux, riche et célèbre. Bon. J'avoue que je ne vois pas bien quoi, et par conséquent je n'en avais pas vraiment besoin. Après tout, ce n'est pas comme si la norme PDF évoluait tous les 3 mois. Si vraiment il me manque une fonctionnalité, je vais la chercher, mais bon sang qu'est-ce que je déteste les marchands d'aspirateurs qui viennent toquer à la dalle de mon écran pour me refourguer leur dernier modèle!
Quelle arrogance! Je n'utilise déjà pas 5% de toutes les fonctionnalités que me proposent tous mes logiciels réunis, et l'autre il arrive, la bouche en fleur, comme si j'avais une demi-seconde à lui consacrer entre ma fonction à coder, la question de mon collègue et le mail qui vient de me tomber dessus, pour savoir si ça m'intéresse de passer à la version 7.2.3.6.c (build 4495) qui me permet d'écrire en chinois et en arabe dans le même champ! Non seulement je m'en fiche comme de mon premier yaourt, mais en plus je trouve ça carrément impoli de m'interrompre dans mon travail pour ce genre de trivialité.

Alors moi je dis: qu'on me laisse, en cliquant dans les menus, rechercher les mises à jour et les installer automatiquement, très bien. Mais les marchands d'aspirateurs, dehors!

Carl chez Ableton

2007-04-05T17:36:00.000+02:00

Le 1er février 2007, j'ai intégré Ableton, où je travaille sur les outils de tests et de qualité.

Ableton, en deux mots, édite le logiciel Live, bien connu dans le monde de la musique électronique. Il s'agit d'un séquenceur (pensez Cubase, Logic ou Pro Tools) dont la spécificité est d'être utilisable comme un véritable instrument sur scène.

Ableton en quelques points :

De grands locaux en plein coeur de Berlin
33 récompenses en 5 ans pour Live
Une superbe machine à café
Une quinzaine de développeurs pour 70 employés
3 repas bio par semaine et des fruits bio à volonté
Un processus de recrutement exceptionnel (cf. le second point)

Plaisir et valeur sociale

2006-10-22T12:41:00.000+02:00

L'autre soir, je discutais avec un jeune étudiant en informatique. En parlant avec lui de ses études, j'appris rapidement qu'il adorait programmer, qu'il venait de finir un projet de classe, une sorte de petit lecteur MP3 qu'il avait développé en Ajax et pour lequel il avait obtenu la meilleure note de sa promotion après avoir bossé dessus comme un fou jour et nuit avec ses deux camarades. Tous les syptômes étaient là : l'emballement, l'œil pétillant, la gesticulation.

Ce jeune homme était complètement mordu de programmation.

Quand je lui ai demandé ce qu'il voulait faire dans la vie, il m'a dit : "Je veux être chef de projet".

Ah?

Un peu surpris, je lui explique qu'en tant que chef de projet, il risque de ne pas programmer beaucoup. Réponse : "Je sais, mais j'ai peur de me lasser du code".

Ah?

Valeur sociale

Le monde français de l'éducation et de l'entreprise, dans le domaine des technologies de l'information comme dans beaucoup d'autres domaines, est gangréné par la prestigiosite. C'est un syndrôme psychologique qui affecte en général plutôt les hommes, âgés de 30 ans ou plus. L'individu affecté est alors sujet à des troubles sévères du jugement et du comportement.

Par exemple, un individu atteint peut émettre des propos incohérents, du type : "Pisser du code, c'est bon pour les indiens. Mon fils, tu seras chef de projet dès ta sortie de l'école de commerce. Tu auras des responsabilités, c'est normal, tu es mon fils ; et tu auras un gros salaire. Mais moi vivant, tu ne seras jamais, tu m'entends ?, jamais technicien."

Chez ces individus-là, le monde est divisé entre ceux qui font et ceux qui décident. Il est bon et noble de décider, mais faire, c'est bien trop en-deçà de leur condition. Programmer, c'est faire ; beurk! Diriger des projets, c'est décider. Yabon!

Les individus qui ont contracté la prestigiosite développent en général d'autres symptômes, parmi lesquels on retrouve, en vrac : un goût marqué pour les réunions, une capacité de travail accrue (il n'est pas rare de les voir rester au bureau jusqu'à 21h), l'impression de tout savoir sur tout, la perte soudaine de tout esprit créatif au travail, une tendance à la déshumanisation (ils se mettent à parler de "ressource" pour dire "personne"), etc.

On comprend alors aisément qu'on retrouve souvent ces individus à des postes de cadres.

Recrutement

Et puis il y a aussi ces enterprises qui ne savent pas recruter. Dans celles-ci, dès qu'un de nos sujets d'étude a du développement à faire faire, il appelle la DRH (ou l'acheteur, si l'entreprise est une grosse consommatrice de prestation de service) en lui donnant la liste de mots-clefs qu'il ou elle doit utiliser pour trouver des candidats. Par exemple: "C#, XML, SOAP".

Celle-ci tape alors ces mots-clefs dans Monster. Elle trouve quelques CV, et applique un algorithme relativement simple :

Un "Epita, .Net, XML". Il n'y a pas marqué "C#". Eliminé.
Un "C#, XML, SOAP, 10 ans d'expérience". Eliminé - pas assez flexible.
Un "Supaéro, C, Automobile". "Supaéro" est un mot-clef spécial qui vaut trois autres mots-clefs dans un CV. Il manque "XML" et "SOAP", mais ils sont ainsi compensés par "Supaéro", avec même encore un peu de marge. Il y a marqué "C", qui ressemble très fort à "C#", et "Automobile" est certainement un plus. Entretien.

L'entretien, c'est bien sûr le moment crucial pour vérifier que le candidat possède réellement les compétences en question. Il s'agit d'être sûr à 100% qu'il convient. Il existe un certain nombre de techniques pour s'en assurer, dont ces DRH gardent jalousement le secret, mais que je connais et dont je vais vous montrer un exemple. Il s'agit de l'épreuve de la "question directe", et c'est l'une des méthodes les plus sûres qui soient. Cela se déroule comme suit - suivez bien, ça va très vite :

"Vous maîtrisez le XML?"

"Oui."

"Parfait. Votre profil nous intéresse. Quand pouvez-vous commencer?"

Subtil, n'est-ce pas? Le commun des mortels n'y voit en général que du feu, mais nos fameuses DRH, elles, savent immédiatement et avec un taux de certitude très élevé que le candidat possède la compétence "XML". Eh! N'est pas DRH qui veut, en France!

Le candidat n'a pas trop parlé de technique, ce qui est toujours bon signe (cela veut dire qu'il n'est pas un "geek", qu'il a des amis, qu'il sort le soir, etc). Et le processus d'embauche de se conclure positivement pour les deux parties sur la signature d'une convention de stage (le candidat n'a que 26 ans), sorte d'outil d'alchimiste qui transforme des "candidats" en "ressources".

Du code, c'est du code

Revenons à notre patient atteint de prestigiosite. Celui-ci trouve ainsi, quelques jours plus tard, la ressource livrée directement devant la porte de son bureau. Il la parque dans sa boquette et lui explique qu'elle trouvera toutes ses instructions dans le document "FRF BPP 3045984 A - Outil de gestion d'informations.doc" (description du projet, méthodes de travail norme ISO, référentiel documentaire, etc). Les toilettes sont au fond du couloir à droite.

L'outil en question a été développé deux ans plus tôt en C#, avec une conception objet relativement soignée et quelques principes plutôt malins mettant en oeuvre la reflectivité du langage. Notre ressource, elle, qui connaît le C (elle a rigoureusement suivi les 18 heures de langage C en première année d'école), et qui devrait donc être parfaitement adaptée à ce projet, parce que la DRH sait exactement comment recruter ce type de profiles, n'a en réalité aucune idée de conception objet, n'utilise que des variables globales, et mettra un désordre sans nom dans le code qui deviendra peu à peu presque impossible à maintenir et qui sera dix ans plus tard remplacé par un outil du marché, très cher, mais qui fonctionne presque.

Evidemment, notre sujet, si par hasard devait lui venir l'idée que la qualité du code de cet outil pouvait avoir un impact quelconque sur sa fonctionnalité (la qualité du code mènerait à la qualité du logiciel), voir même, hérésie!, sur le fonctionnement de son équipe ou même de l'entreprise (la qualité du logiciel mènerait à la qualité du travail), verrait alors que la ressource en question n'était manifestement pas adaptée à ce projet.

Mais soyez rassurés : cette idée ne lui viendra pas. Tout simplement parce que du code, ce n'est "que du code".

Car pour notre sujet, la qualité d'un logiciel n'est liée qu'à la qualité du cahier des charges et du plan de recette. Il n'existe absolument aucune relation entre le code produit par la ressource et la qualité du logiciel. Aucune. C'est parfaitement indépendant. Et c'est bien pour ça qu'il aurait finalement bien mieux valu faire faire ce développement par Sasken en Inde. Ils écrivent des choses comme

for (i = 1; i <= 3; i++)
{
switch (i)
{
case 1: f1(); break;
case 2: f2(); break;
case 3: f3(); break;
}
}

mais au moins ils ne sont pas chers.

Le résultat net

Le résultat net de cette attitude, c'est que les jeunes qui arrivent sur le marché du travail en ayant envie de coder sont très fortement dévalorisés. Leurs compétences ne sont pas reconnues, ou le sont mal (note: "C" != "C#"). Ils sont employés à faire un travail considéré comme bas de gamme, et lorsqu'ils ont envie de proposer des solutions qui leur permettraient de faire les choses bien, on leur répond qu'on n'a ni le temps ni le budget et que de toute façon, on n'en a rien à faire si c'est amusant ou pas, l'important c'est que le cahier des charges et les délais soient respectés, et que c'est comme ça la vie, et que tu vois, je te l'avais bien dit que le code ça t'ennuierait, mais garde espoir petit homme, après 12 mois de stage puis 24 mois de CDD tu auras assez d'expérience pour devenir chef de projet junior et là tu pourras décider de ce que les moines copistes, pardon, les codeurs, feront ou ne feront pas, et tu gagneras plus de sous, et tu seras enfin un homme.

Bisque, bisque rage.

Développeurs, choisissez mieux

Quand on est jeune, bien sûr, et en particulier quand on sort de l'école, le choix de l'entreprise dans laquelle on va travailler n'est pas si libre que ça. Il faut sans doute passer par quelques années d'expérience pas follichonnes pour pouvoir accéder ensuite aux bons jobs.

Néanmoins, il est bon de connaître les signes qui permettent de faire la différence entre les entreprises où les développeurs sont respectés pour ce qu'ils sont, c'est-à-dire souvent les véritables artisans du succès commercial d'un produit, et pas vus comme des moines copistes mis à la disposition du manager polytechnicien qui, lui, sait tout.

Remarquez que quand je parle de Supaéro, de Polytechnique ou de l'Epita, je ne juge aucune de ces écoles. Je critique par contre l'importance que prend le nom de l'école sur le CV auprès des recruteurs. Personnellement, je n'ai jamais trouvé de relation directe entre le talent d'un développeur et l'école dont il sort. C'est parce que Les bons développeurs, je crois, ont appris chez eux dans leur chambre plutôt que sur les bancs de la fac.

Or donc, si vous cherchez une entreprise où vous pourrez vraiment vous éclater, voici quelques signes intéressants :

C'est un éditeur de logiciel. Eh! oui, ça paraît bête, mais c'est vraiment chez les éditeurs qu'on trouve le code le plus intéressant à écrire. En société de service, le développement peut être très intéressant, et vous aurez l'occasion de découvrir des tas de choses souvent un peu exclusives, mais vous n'aurez pas la notion de produit, de qualité parce qu'on aime la qualité, etc, et les choix de fonctionnaltiés seront très souvent faits par d'autres.
Vous êtes recruté par des développeurs. Personne ne peut mieux juger des compétences d'un développeur qu'un autre développeur. Il est rare de ne voir aucune DRH durant le processus de recrutement, mais si c'est un développeur qui vous contacte et qui est présent lors de votre entretien, c'est déjà bon signe.
Cherchez les tests pratiques! Pas les tests psychométriques, non. Je veux parler de code. Le seul moyen de s'assurer qu'un développeur sait programmer, c'est de le faire programmer. Sur papier ou sur ordinateur, ce n'est pas grave, l'important c'est d'écrire du code et d'en parler. Certaines entreprises envoient un exercice de programmation à faire chez soi, d'autres vous demanderont d'écrire du C sur un tableau blanc à l'entretien. Attention toutefois aux QCM: n'importe quel HEC peut imprimer un QCM et comparer vos réponses avec la liste préétablie des réponses attendues. Programmer devant le recruteur, en discuter ensuite avec lui, c'est en général très bon signe.
Un développeur travaille avec son cerveau, tout comme les écrivains. Les écrivains qui peuvent écrire dans le bruit, de 9h à 18h, avec la même efficacité chaque jour ne sont pas nombreux. Les développeurs, pareil! Si l'endroit est calme et que les horaires sont flexibles, ce n'est pas forcément signe de gestion débonnaire et de farniente, c'est peut-être tout simplement le signe que l'entreprise à su mettre en place des conditions de travail favorables aux développeurs. A l'inverse, si on vous montre un océan de boquettes avec des téléphones qui sonnent toutes les dix secondes et une horloge pointeuse à côté de la porte d'entrée, ce n'est pas forcément signe que l'entreprise ne sait pas développer, mais ça peut indiquer qu'elle n'est pas tout à fait en phase avec les besoins de base des développeurs.
Pas de recherche par mot-clef! Si l'entreprise développe en Java, et qu'elle ne veut entendre parler que de gens qui connaissent parfaitement le Java, méfiance. Un bon développeur peut apprendre un nouveau langage en quelques semaines, surtout s'il en connaît déjà plusieurs, ce qui est presque toujours le cas, et ses acquis dans d'autres langages sont souvent un avantage précieux. Discriminer sur les langages et technologies maîtrisés par le candidat n'est pas un bon signe.
Des livres! Même si les développeurs trouvent aujourd'hui énormément d'information sur Internet, il y a un certain nombre de livres qui sont véritablement des mines d'or. Même si cela risque d'évoluer à l'avenir, un bon livre sur un sujet précis reste aujourd'hui la meilleure source d'informations techniques. Alors si on vous montre une belle bibliothèque fournie qui contient trois Stroustrup, le Brooks, les Knuth et quelques Tannenbaum, ou qu'on vous raconte qu'on achète volontiers des livres à la demande des développeurs, c'est très bon signe. Ca veut dire qu'ils ont au moins le soucis d'être bons. Et au passage, ça paraît bête à dire, mais assurez-vous que l'entreprise laisse l'accès à Internet à ses employés - croyez-moi, ce n'est pas le cas partout.

Conclusion

Alors jeune développeur, si tu aimes le code, tant mieux pour toi, tu pouras faire l'un des métiers les plus passionnants et les plus intellectuellement stimulants qui soient! Cherche une entreprise où le code est intéressant plutôt que de chercher une voie qui t'évitera de constater que le code peut ne pas l'être. La prochaine fois que tu pars en entretien, relis cette liste et garde-la en mémoire - peut-être te permettra-t-elle de trouver dès le début, ou du moins assez vite, une entreprise qui saura te valoriser.

Gramophonies - Mission Accomplie

2006-06-29T07:24:00.000+02:00

Une grande salle plongée dans l'obscurité, à peine éclairée par les ampoules et les néons de lumière noire. Des petite formes roses, qui semblent briller par elles-mêmes, hantent les murs et le sol. Autant de petits gramophones, regroupés en communautés aux noms étranges ; les Brontophones semblent converser entre eux et les Sisyphones jettent leurs sons comme des soleils, tandis que les Cylindrophones semblent médusés dans leur désordre apparent. Par terre, immobiles, les Suprêmophones imposent leur discipline, et surveillent les Fleurs du coin de l'œil.

Puis, soudain, Thomas A. Edison se fait entendre partout dans la salle. Il nous raconte la naissance de l'enregistrement sonore et nous livre ses secrets sur sa vie et ses travaux...

Pour en savoir plus, visitez-donc le site de l'installation sonore Gramophonies.

Gramophonies à CitySonics, J-7

2006-06-15T11:29:00.000+02:00

L'installation sonore à laquelle je collabore, Gramophonies, va être exposée au festival CitySonics à Mons, en Belgique. Le vernissage est le 22 juin vers 18h, et le cortège part de la Salle Saint-Georges, qui nous est réservée (association Théâtre Electronique).

En attendant, c'est le rush intégral. Il reste dix millions de choses à faire, souder des câbles, installer l'ordinateur qui va diffuser les textes d'Edison pendant un mois et demi, tester la configuration audio (par ailleurs fort alléchante avec sa carte RME HDSP9652 et ses trois convertisseurs ADA8000 de chez Behringer, pour 24 sorties audio au total), concevoir encore quelques circuits électroniques, mouler les derniers socles de gramophones (Yann est en passe de devenir l'un des experts les plus en pointe à Paris sur le moulage d'objets en polyuréthane dans des moules en silicone), etc.

Mais le résultat promet! Pour voir l'installation, passez donc par Mons cet été.

Ingénieurs, à vos CV!

2006-06-08T09:59:00.000+02:00

Mon employeur, AKKA Technologies, recrute à tour de bras en ce moment.

Si vous êtes ingénieur en informatique, en électronique, en mécanique ou dans n'importe quel domaine apparenté, envoyez-moi votre CV. Les domaines de prédilection d'AKKA sont la défense, les télécommunications, les transports et l'aéronautique. Amis de province, AKKA est peut-être aussi présent près de chez vous !

La responsable recrutement et la directrice des ressources humaines habitent toutes les deux à quelques mètres de mon bureau, alors profitez-en.

Comment j'en suis venu aux tests unitaires

2006-05-25T20:35:00.000+02:00

Pour certains, les tests unitaires sont la plus grande invention depuis l'eau tiède. Au point même qu'on peut articuler toute l'activité logicielle autour de ces fameux tests unitaires et en faire le bœuf qui tire la charrue.

Pour d'autres, les tests unitaires sont une perte de temps, une façon débile de doubler le volume de code à maintenir. Doubler, voire plus...

Lorsque j'ai lu eXtreme Programming de Kent Beck, j'étais emballé par la façon de penser de cette méthode, mais le seul point sur lequel je n'émettais aucune réserve était celui sur les tests unitaires.

Je n'écris pas cet article pour faire l'apologie du test unitaire. Les tests unitaires font maintenant partie de ma "boîte à outil du développeur" et j'y ai recours quand je l'estime nécessaire, mais point trop n'en faut : ils ne sont pas toujours indispensables. Cet article raconte plutôt comment j'ai découvert et utilisé les tests unitaires dans mes divers projets.

Le Beck dans l'eau

Ma première rencontre avec les tests unitaires fut donc par l'intermédiaire du livre de Kent Beck, le créateur de la méthodologie eXtreme Programming. C'était à la demande de Denis Gueyffier, mon patron chez eNetshare, qui voulait que je lise ce livre pour éventuellement appliquer XP au développement de notre outil de travail collaboratif. Nous n'avons finalement pas mis en œuvre XP chez nous, mais les idées me plaisaient.

Chez moi, sur un petit projet de mon cru, j'ai donc décidé d'essayer, à l'aide de CppUnit. J'avais très rapidement écrit la veille une classe de pointeurs automatiques dont j'avais besoin pour mon projet ; j'avais fait le service minimum pour que le code fonctionne pour mes besoins du moment. J'ai donc repris cette classe et écrit les quelques tests nécessaires pour valider ce que j'avais fait. J'ai compilé, puis lancé les tests. Boum! Deux bugs d'un coup ; j'étais convaincu.

Après les avoir corrigés, j'avais la preuve que mon pointeur automatique fonctionnait bien. Ce n'était plus le trop-plein de confiance du programmeur éternellement arrogant qui se dit "cette fois c'est sûr, c'était le dernier bug". J'avais balayé tous les cas possibles d'utilisation de ma classe, et j'avais la preuve que ça fonctionnait. Je n'avais jamais eu ce niveau de confiance dans mon code auparavant. J'ai donc décidé à ce moment-là que les tests unitaires étaient une bonne chose.

En retournant au travail le lendemain, j'ai tenté d'expliquer à mon collègue développeur pourquoi je pensais que les tests unitaires étaient une très bonne chose. J'étais tellement emballé par cette pratique que sa réponse me décontenança un peu : "ça à l'air pénible, il faut modifier les tests à chaque fois qu'on modifie l'objet testé".

Certains sont parfois atrophiés de la vision à moyen et long terme.

Pas assez de tests, Petit Scarabée

Plus tard, j'avais à écrire un outil d'exécution de tests automatiques. L'outil était capable d'exécuter des scripts en VBScript en utilisant un composant COM de chez Microsoft, mais afin de le rendre plus intelligent, il fallait que l'outil comprenne par lui-même, au moins dans une certaine mesure, la syntaxe du VBScript. Il y fallait donc écrire un petit parser. En soi, c'est déjà un cas où l'utilisation des tests unitaires se révèle très bénéfique.

Mon responsable avait décidé de recruter une stagiaire pour m'aider dans ma tâche. Cette stagiaire n'avait malheureusement jamais programmé d'algorithmes aussi complexes. J'ai donc décidé de lui faire faire le travail en utilisant les tests unitaires : je lui fournissait une fonction vide documentée et une batterie de tests unitaires, et son boulot était d'écrire le corps de la fonction pour que les tests unitaires passent.

Au final, cette façon de faire m'a pris plus de temps que si j'avais fait le travail moi-même, mais cela permit à ma stagiaire de progresser de manière remarquable. C'était aussi une belle illustration d'un des principes invoqués par les évangélistes du test unitaire : une fois que le test passe, on a fini. La consigne de ma stagiaire était donc : "fais ce qu'il faut pour que les tests passent, puis passe à la suite." La tentation est grande, quand on est jeune développeur, de passer beaucoup de temps à polir et à peaufiner son code, souvent en pure perte. Là, pas de problème, le test servait d'indicateur pour dire que le travail était fait. Et moi je savais qu'il était bien fait.

Bien sûr, je me suis fait avoir. Pour l'une des fonctions, j'avais écrit un test un peu trop simpliste, et la fonction qui en résulta fut très simpliste aussi. Mais le plus important était qu'elle faisait ce qu'on lui demandait. Les tests unitaires ne sont pas un moyen miraculeux pour écrire du code sans faute. Je vois l'avantage comme ceci : la probabilité d'avoir un bug non découvert lorsqu'on met en place des tests unitaires diminue fortement dans la mesure où il doit se trouver dans le code testé et dans le test.

C#, précis, pointu

Aujourd'hui, je travaille à nouveau sur une sorte de parser. J'adooooore les parsers. Le "programme" est écrit sous forme de tableau Excel et mon outil, écrit en C#, lit ce tableau Excel et génère en résultat une séquence correspondante dans un autre environnemment appelé TestStand.

Comme je ne connaissais pas C# et que je n'avais jamais piloté Excel ni TestStand depuis un environnemment .Net, je décidai rapidement de me reposer largement sur les tests unitaires (avec NUnit), qui me permettraient à la fois de valider mes suppositions sur le fonctionnement de ces trois APIs et de valider mes algorithmes d'analyse lexicale.

Et c'est donc comme ça que je travaille aujourd'hui. Dès que je veux faire quelque chose que je n'ai pas encore fait avec Excel piloté par C#, j'écris un test unitaire, qui va lire dans l'un de mes fichiers de tests, pour valider ma compréhension sur le sujet. Une fois que mes tests passent, je sais que je peux l'utiliser en confiance dans mon programme.

C'est un autre point important des tests unitaires que cet exemple illustre : les tests unitaires peuvent permettre de valider un composant logiciel exterieur. Rien de tel qu'une batterie de tests pour savoir comment fonctionne un composant exterieur.

Et ce n'est pas fini ! Récemment, j'ai vu surgir un bug étrange, qui semblait aléatoire. Avec des points d'arrêts bien placés, j'ai fini par comprendre quelle séquence d'appels faisaient apparaître ce bug. J'ai immédiatement mis en place un test unitaire pour reproduire, dans une sorte d'environnement de laboratoire, cette même séquence d'appels. Effectivement, en exécutant ce test, le bug se reproduisait. J'avais donc un moyen simple de réexécuter cette séquence pathogène à volonté, jusqu'à ce que je parvienne à isoler la cause du bug. Et ça, c'est vraiment confortable. Le test est bien sûr toujours là, et s'assure que le bug ne resurgisse pas (sous cette forme, du moins).

Not an addict

Si vous jettez un œil aux sources de Poseidon, vous verrez qu'il y a en tout et pour tout... 1 test unitaire.

Poseidon est un synthétiseur virtuel, et de ce fait, il s'agit d'une boîte dans laquelle il y a des objets qui synthétisent ou traitent du son et qui se passent ce son entre eux pour créer finalement le son final. Les algorithmes sont essentiellement des algorithmes de traitement du son, et décider si un tel algorithme est bien implémenté relève plus souvent du subjectif que de l'objectif.

Mis à part le traitement du son, il y a assez peu d'algorithmes logiques. Il y en a un très rudimentaire pour décider de l'affectation des voix en fonction des touches enfoncées, quelques lignes pour analyser des données MIDI en entrée, et c'est à peu près tout. Depuis le début du développement, je n'ai eu en tout et pour tout qu'une dizaine de bugs, et ce n'est pas parce que je suis un génie, mais bien parce que structurellement et algorithmiquement, ce logiciel est très simple.

Je n'ai donc pas écrit de batterie de tests unitaires pour Poseidon. En fait, j'écris essentiellement des tests pour les algorithmes logiques et calculatoires, et pour les structures de données, car ce sont ceux qui apportent le plus de plus-value.

Ceux qui disent que les tests unitaires ne servent à rien, je les invite à essayer : pour certains types de code, c'est l'une des méthodes les plus efficaces pour chasser le bug. Je ne crois pas cependant que ce soit la panacée, comme les gens du Test-Driven Development voudraient nous faire croire. Finalement, les tests unitaires, c'est comme les pommes : "An apple a day keeps the doctor away", mais, gros mangeurs : gare au sucre !

Poseidon

2006-03-29T12:31:00.000+02:00

Comme j'ai un peu de temps libre ces derniers jours, j'ai fait quelque chose que je n'avais pas fait depuis longtemps. J'ai passé le week-end entier à programmer. Du vendredi matin au lundi matin, une seule nuit de sommeil, un vrai marathon de bonheur que je n'avais pas couru depuis longtemps.

Le résultat se nomme Poseidon, un synthétiseur virtuel à modélisation analogique, ou "virtual analog". Il y a des oscillateurs qui produisent des formes d'ondes simples, des filtres pour les traiter un peu, des amplificateurs pour donner une dynamique au son et des composants qui génèrent des valeurs de manière automatique pour pouvoir contrôler les trois premiers. Les synthétiseurs construits sur ce type se prêtent très bien à l'expérimentation sonore.

Si vous êtes curieux, Poseidon possède sa propre page web. Allez-donc lui rendre visite, ça lui fera plaisir.

Startups et logiciels V - Démo Niaque

2006-03-03T10:07:00.000+01:00

Que ce soit pour les investisseurs, les gros clients ou les enthousiastes influents qui vont disséminer au grand public la bonne parole sur vous et votre produit, il vous faudra sans doute un jour passer par la case démonstration. Saurez-vous esquiver la peau de banane ?

Pourquoi faire des démonstrations ?

Prenez n'importe quel éditeur de logiciel – allez, au hasard, Compuware – et cherchez leur page produits. Vous allez voir, ça va vous paraître familier :

La dernière version d’Uniface, basée sur XML, ouvre la porte à l’automatisation des processus métier et des échanges B2B, devenant ainsi la solution globale pour les acteurs du e-commerce de 2nde génération.

Allez, soyez franc : vous n'avez rien compris à ce que fait Uniface. Il suffit d'aller un peu sur les sites des gros éditeurs de logiciels (et des moins gros) pour trouver une pléthore de descriptions comme celle-ci, avec tous les mots à la mode : XML, B2B, globale, e-commerce, 2nde génération – vous remarquez comme ça s'intensifie vers la fin ?

Le problème, c'est que ce genre de langage techno-marketing est depuis longtemps la norme dans l'industrie du logiciel. Si les gens du marketing chez Compuware avaient écrit quelque chose de compréhensible, on ne les aurait tout simplement pas pris au sérieux. C'est dommage mais c'est comme ça.

Les startups sont tentées de faire la même chose, et c'est tout à fait normal. Regardez eNetshare : "logiciels innovants pour accélérer et sécuriser la messagerie électronique et les outils de collaboration de l'entreprise". Et ce qui est génial, c'est que tout le monde joue au jeu du plus-c'est-fumeux-mieux-c'est, y compris les investisseurs et les gros clients. Si votre paragraphe de présentation n'est pas fumeux au possible, vous ne les attirerez jamais.

Je me moque un peu du marketing des T.I., mais n'oublions pas un autre problème, lié au grand public : même si vous vous adressez aux gens avec des mots simples, le risque demeure que peu d'entre eux comprennent vraiment à quoi sert votre logiciel.

Dès lors que les mots ne suffisent plus pour expliquer la fonction d'un logiciel, la démonstration s'impose comme une évidence. La seule véritable façon de s'assurer que le quidam ait bien compris ce que fait votre produit, c'est tout simplement de lui montrer.

Enfin, n'oubliez pas votre manager. Si vous faites un travail de développement, des démonstrations probantes à votre responsable augmenteront vos chances de pouvoir continuer votre travail tranquillement, ou même d'avoir plus de liberté. Ce n'est pas négligeable, surtout lorsque vous travaillez seul dans votre coin.

L'effet démo

Vous avez sans doute déjà entendu parler de l'effet démo. Il y a même de fortes chances que vous l'ayez déjà vécu. Exemple classique : l'un de vos développeurs arrive tout emballé dans votre bureau en vous disant qu'il a fini de programmer la fonction "Schmilblick instantané" et que c'est absolument génial, ça marche trop bien! et il faut absolument que vous veniez voir ça tout de suite. Bon, vous finissez de peaufiner votre présentation PowerPoint, celle à laquelle personne ne va rien comprendre, si tout se passe bien, et une heure plus tard, vous allez le voir. Il clique fièrement sur le bouton "Schmilblick" et... le programme plante. Bien sûr, il ne comprend pas, normalement ça marche, il doit y avoir un problème avec le réseau, à moins que ça ne soit la boule à plasma que le collègue d'en face vient de ramener du Nature Découvertes du bout de la rue. Il devient rouge, il bafouille, puis finit par abandonner, tout penaud, en disant "Je ne comprends pas, ça marchait il y a cinq minutes!"

L'effet démo, cette anomalie des lois de la nature qui veut que tout fonctionne très bien, sauf au moment où on fait une démonstration devant quelqu'un d'autre, n'est pas inévitable. Vous aurez sans doute des surprises, mais vous pouvez au moins vous prémunir contre les plantages et autres catastrophes le jour J.

Répétez. Une démonstration, ça ne s'improvise pas. Faites-la deux, trois, quatre fois avant, devant vos collègues, amis, cousins, poisson rouge, miroir, c'est votre choix, mais répétez. Vous vous rendrez vite compte des choses à ne pas faire, mais aussi des choses qui en jettent. Soyons honnêtes, une démonstration c'est du marketing, alors il faut que ça tape! Repérez les manipulations qui en jettent et évitez celles qui ralentissent votre logiciel ou qu'il gère maladroitement.

Quoi qu'il en soit, assurez-vous que tout fonctionne pendant les répétitions. Lors du live, ne changez rien ! La tentation est grande, pour un développeur, de rajouter en dernière minute un bout de code génial, exprès pour la démo. Formellement interdit ! Votre démonstration doit se faire dans les Conditions Normales de Température et de Pression, en environnement contrôlé. Entre le moment où vous commencez les répétitions et la fin de votre grand show, rien ne doit changer, si ce n'est les corrections les plus indispensables sans lesquelles la démo serait un échec. Conservez le même code source, les mêmes binaires, les mêmes ordinateurs, le même rétroprojecteur, la même salle, la même configuration réseau (et la même prise réseau dans le mur)... vous m'avez compris, pas besoin d'en rajouter.

Pensez à faire un plan, un chemin clair à travers vos fonctionnalités, de manière à ce que les spectateurs puissent construire mentalement une image de plus en plus large de votre application. Commencez par les fonctions essentielles, puis repassez éventuellement une seconde couche pour les détails-qui-tuent.

La démonstration doit être un exercice vivant et détendu. Préparez volontiers quelques blagues aux moments opportuns – l'humour est un formidable moyen de s'incruster dans l'esprit des spectateurs. Si vous avez une petite fonctionnalité qu'il faut que le client retienne, accompagnez-la d'une petite plaisanterie. Mémorisation garantie ! Soyez souriant et confiant, votre confiance contaminera votre auditoire.

Hey, teachers, leave those kids alone!

Bien. Maintenant que je vous ai expliqué que vous ne deviez rien laisser au hasard, je vais vous expliquer tout le contraire. Phase 2 : laissez vos spectateurs prendre les commandes. Vos clients seront déjà contents de voir dans la pratique comment fonctionne votre produit, mais ils seront souvent carrément enthousiasmés à l'idée de l'essayer !

Un jour, un groupe de clients italiens étaient venus exprès pour voir une démo chez eNetshare. Ils avaient tous l'air très sérieux et posaient des questions raisonnables lorsque nous leur montrions le logiciel, mais quand nous leur avons proposé de l'essayer à leur tour, changement de ton. Notre logiciel avait un sacré potentiel fun : du chat et des fichiers partagés. L'un ouvrait un fichier, y inscrivait "toto" et le refermait, l'autre sur un autre poste l'ouvrait, voyait le "toto" et y rajoutait "est beau" etc. et le tout en se lançant des petites vannes par messagerie instantanée. Pendant quelques minutes, on aurait dit des gamins. Quand vous constatez cela, vous savez que votre démonstration aura fait son petit effet.

Mais alors attention ! C'est sûr et certain, l'un d'entre eux va tenter une manipulation imprévue. A ce moment-là, vous ne pourrez pas lui sauter sur le bras pour l'empêcher de taper sur Entrée. Ne dites jamais à quelqu'un qui essaye votre logiciel : "Stop ! Ne faites pas ça !"

Vous devez être sûr que votre logiciel est blindé. Trop souvent, les développeurs laissent des cas imprévus, des boutons qui ne font rien et des fuites mémoire en se disant que de toute façon, ce n'est qu'une démonstration, ce n'est pas le produit fini. Erreur !

Le deuxième effet démo

Celui qui vient voir votre démonstration vient pour se faire une idée de ce que sera le produit fini. Il peut parfaitement comprendre que tout ne soit pas fait (en tout cas au niveau des détails – il s'attendra probablement à ce que toutes les grosses fonctionnalités soient présentes), mais comme me disait souvent Denis : les gens ne savent pas ce que c'est qu'un bug. Ils ne comprennent pas comment l'application peut disparaître soudainement alors qu'ils viennent de cliquer sur un bouton, surtout si on leur explique derrière que "c'est normal, ce n'est pas fini".

Tous vos efforts pour créer une bonne image de votre produit peuvent tomber en ruine en une demi-seconde si le logiciel plante. Vous aurez beau dire que vous n'avez pas encore eu le temps de tout régler, etc., si votre programme plante, c'est mal. S'il ne produit pas l'effet attendu, c'est mal. S'il est lent ou moche, c'est mal, mal, mal. Vos spectateurs retiendront mille fois mieux les erreurs et les dysfonctionnements que les points positifs et les belles images. C'est dommage, certes, mais c'est comme ça. Vous devez tout faire pour ne pas laisser une mauvaise impression.

Rêgle d'or : pas de plantage. Plantage interdit. Un point c'est tout.

Evitez également les boutons-qui-ne-font-rien-quand-on-appuie-dessus. Ce n'est pas très grave en soi, la personne qui aura cliqué pourra comprendre que vous n'avez pas encore travaillé à cette partie là. Mais il lui restera quand même le souvenir du moment de surprise et de doute quand, juste après le clic de souris, il ne s'est strictement rien passé. Votre IHM peut montrer des fonctionnalités qui ne sont pas encore implémentées, mais assurez-vous alors que les boutons, les éléments de menus ou les cases à cocher correspondantes soient désactivées (grisées). Et quand l'utilisateur vous pose la question, soyez positif et dites "oui, c'est prévu", ne dites pas "on n'a pas encore eu le temps de le faire". Il faut convaincre votre auditoire que vous maîtrisez votre développement.

La vie est injuste : les gens vous reprocheront vos défauts, et oublieront vite vos qualités. Si vous laissez vos clients ou vos investisseurs potentiels voir un produit bancal, le dommage est considérable. Ils auront définitivement l'impression que vous n'avez pas fait votre boulot correctement. Il n'y a que les informaticiens qui savent que le développement d'un logiciel fait partie des plus complexes de toutes les activités humaines. Les autres, ils se disent juste que ça doit fonctionner, point barre. Ils ne veulent pas de jérémiade ni d'excuse, ils veulent voir un bon produit. Rattraper une mauvaise impression est dès lors très difficile. Si votre démonstration exhibe des anomalies et des maladresses, ceux qui l'auront vue raconteront aux autres que ça ne marchait pas bien, et ni les uns ni les autres n'auront très envie de voir comment se porte votre logiciel trois mois plus tard. C'est presque à coup sûr une clientèle perdue, et une mauvaise image pour vous. Et perdre des clients peut se révéler fatal pour une startup.

L'essayer, c'est l'adopter

A la conférence "The Future of Web Apps", Joshua Schachter, le créateur de del.icio.us, parle de ces sites qui imposent à l'utilisateur de s'inscrire avant de pouvoir faire quoi ce que soit.

Les utilisateurs veulent se faire une bonne idée de ce qu'ils vont avoir s'ils s'inscrivent. Ce n'est pas quelque chose que vous pouvez leur dire, ils ne le liront pas. Alors vous devez leur montrer, vous devez les laisser se balader, pour qu'ils aient un aperçu de ce qui se passe sur votre site, de ce qu'il fait et de ce que ça veut dire.

Proposer une version d'essai de son produit est monnaie courante dans le monde du logiciel, mais chacun le fait à sa manière. Les meilleures formules, à mon avis, sont du type "gratuit pendant trois semaines". Les versions bridées qui ne vous permettent pas d'enregistrer votre travail, ou qui vous affichent de la publicité ou (encore pire) des popups toutes les heures pour vous rappeler qu'il faut payer laissent immanquablement dans l'esprit de l'utilisateur une connotation négative.

L'approche de sites comme del.icio.us ou flickr.com est plus saine : l'utilisateur peut déjà faire pas mal de choses, et notamment consulter (à défaut de pouvoir contribuer). S'il a envie de franchir le pas, il s'inscrira d'autant plus volontiers qu'il n'aura pas été harcelé par des popups et des messages subliminaux à la discrétion pachydermique.

La démonstration, plus efficace que les descriptions marketing, permet à un client, à un investisseur ou à votre manager de se faire une bonne idée de ce que fait votre logiciel. Enthousiasmer le spectateur est un puissant moyen de gagner sa confiance, mais attention - le moindre accroc peut ruiner tous vos efforts.

Table des matières

2006-02-28T12:24:00.004+01:00

Voici l'ensemble des articles importants publiés sur ce blog. Cette page sera toujours accessible par un lien sur la partie droite de l'écran. Mise à jour manuelle - retards garantis!

Ouverture - 27/10/2005
A Propos de l'Auteur - 03/11/2005
Startups et logiciels I - Gestion des sources - 15/11/2005
La Fin Du Program Files ? - 17/11/2005
L'Installation En Un Clic - 21/11/2005
Startups et logiciels II - Haro sur les bugs - 24/11/2005
Startups et logiciels III - Automatiser les compilations - 03/12/2005
Startups et logiciels IV - Touche Pas A Mon Soft ! - 15/12/2005
The Mythical Man-Month - Du Mythe à la Réalité - 31/12/2005
Asserter n'est pas jouer - 04/01/2006
La Guerre Des Mondes - 10/01/2006
Il y a du Bon C++ et du Mauvais C++ - 09/02/2006
Startups et logiciels V - Démo Niaque - 03/03/2006
Comment j'en suis venu aux tests unitaires - 25/05/2006
Plaisir et valeur sociale - 22/10/2006
Colportage virtuel - 16/06/2007
Le Marteau - 02/12/2007
L'Informatique Sentimentale - 21/01/2008
Estimations et plannings - 10/02/2008
Logiciel - Industrie ou Artisanat? - 24/02/2008
Critique: Multithreading - 11/03/2008
Mon carnet et moi - 05/06/2008
Comprendre les niveaux de garantie de sécurité face aux exceptions - 18/06/2008
Bien utiliser assert() - 24/06/2008

Frappant!

2006-02-13T13:36:00.000+01:00

Quelque part entre l'Afrique et le Brésil, il y a le rythme. C'est une magnifique leçon de musique, d'énergie, de partage et d'écoute que nous ont proposé dimanche après-midi, lors de l'événement musical Afrique/Brésil "Saudade do Saka-Saka", au Cabaret Sauvage à la Vilette, trois percussionnistes incroyables : Simone Soul (Brésil), Adama Dramé (Burkina Fasso) et Silvano Michelino (Brésil-France).

Le mélange entre rythmes brésiliens et africains, aux mains de ces virtuoses, prend vraiment, et si personne ne s'est levé pour danser au milieu de tous, clairement toute la salle balançait du torse. Simone Soul en particulier, avec un magnétisme incroyable, est parvenue à nous transporter pour une petite heure dans un autre monde. Merci à elle, et merci à Adama Dramé et à Silvano Michelino pour ce moment de bonheur préparé au shaker.