La claque de la journée.
Neal est à mon avis l’un des meilleurs speakers de cette première journée. Il est passé la semaine dernière à Zurich à Jazoon, et j’avais beaucoup apprécié la fin de sa présentation, regrettant de ne pas l’avoir vue en entier.
C’est donc avec plaisir que j’ai découvert qu’OCTO l’avait invité à l’USI cette année.
Et bien je vais vous dire : ce gars est une bête.
161 slides en 55 minutes !
Je suis allé discuter avec lui et Guillaume Laforge rapidement après la présentation. Tout simplement un performer, qui a déjà fait plus de 100 présentations, une bête de scène. Le fond, la forme, tout était parfait.
Attachez votre ceinture, on y va.
La présentation s’intitule « Les philosophes d’antan et la foire aux embrouilles« . Neal arrive sur scène. Avec son petit ventre, il passe derrière le micro et commence « Neal Ford, ThoughtWorks, Américain comme mon ventre vous le montre (rires dans la salle), bonjour à tous« .
Les lumières se baissent, le show commence.
Tout d’abord un petit retour en arrière : « Those who cannot learn from history are doomed to repeat-it ». Il débute son sujet par une introduction en nous expliquant comment les philosophes avaient déjà résolu certains de nos problèmes. L’un de nos gros défauts est de ne pas regarder le passé. Il montre ainsi ce livre de Kent Beck « SmallTalk best practice » de 1996 où avant l’arrivée de Java, des chapitres entiers louaient SmallTalk en pensant que ce serai le langage des années 2000. Avons-nous appris quelque chose du passé ? Comment devons-nous nous comporter et nous adapter afin de ne pas répéter les mêmes erreurs ?
Platon avait déjà inventé le concept de Class et d’Instance. Nous mêmes dans notre vie quotidienne, nous voyons ce concept chaque jour sans nous en rendre compte. Prenez cette chaîne de restauration américaine. Lorsque vous voyez la tête de ce super hamburger sur l’affiche, une larme vous coule presque tellement cette photo est belle. Ensuite, une fois servi, la chose molle et fumante qui sort de cette petite boîte en carton, c’est pourtant bien ce que vous avez demandé non ? La Class est la photo, l’Instance est ce que vous obtenez. Il y a une différence entre ce que l’on spécifie et ce que l’on obtient. Platon 1 – la Salle 0
D’ailleurs Platon aurait détesté le JavaScript. Pour lui tout doit être objet, peut-être même à outrance. Mais son problème était qu’il lui manquait la logique.
Aristote ensuite pose les bases de la logique moderne. Il définit 2 notions que nous pouvons appliquer chaque jour : «the essential property» et «the accidental property». Chaque objet a des propriétés fondamentales. Par extension il a des propriétés accidentelles, supplémentaires. Des effets de bords. On reviendra sur ce point dans quelques minutes.
Galilée aurait été un excellent Architecture SOA. Il ne croyait personne, il souhaitait vérifier tout lui même. Pour chaque cas, il mettait en place une expérience (un test) afin de valider son postulat. Neal explique ainsi qu’il aimait bien balancer toutes sortes de choses de la tour de Pise, quoique je ne pense pas que les 2 soient de la même époque. Mais bon, l’image est là pour nous expliquer que l’expérimentation est donc importante. Il explique ainsi que la contre-intuition conduit à la vérité. Nous devons donc apprendre de l’histoire que l’homme s’est souvent trompé. La Terre était plate avant que Galilée ne démontre le contraire, et nous devons donc ne pas répeter les mêmes erreurs que le passé.
Neal présente ensuite le site c2.com qui liste des anti-patterns appliqués dans notre industrie. Il nous supplie de prendre le temps de lire ces anti-patterns qui démontrent que la croyance commune pour certains problèmes informatique a tord. Il passe ensuite en revue quelques patterns comme «Dead End» ou le cul-de-sac. Ce pattern s’applique à des projets qui vont se planter, où tout le monde presque le sait, mais où l’on continue en pensant qu’une hypothétique solution est possible. Aïe cela fait mal.
Le pattern ensuite de la «Dart cible» : votre chef vient vous voir et il vous demande «Donne moi une estimation maintenant». Alors vous répondez avec une estimation en jours, en expliquant que celle-ci n’est pas certaine. Oui pas de problèmes dit votre chef, je sais que ce n’est qu’une estimation. L’anti-pattern s’active lorsque votre chef amnésique oublie que ce n’était QU’UNE ESTIMATION…
Il aborde ensuite les projets «Mushroom» ou «Champignon de Paris». Il s’agit de projet où l’équipe de développement est coupé de la lumière et crache son produit sans jamais rencontrer un client final… Levez la main ceux qui sont concernés ?
L’anti-pattern «Standing of the Shoulders of Midgets» est assez connue et dramatique. Voici comment je le résume «Vous devez utiliser Oracle Portayeu parce que la politique des achats c’est Oracle». C’est donc le pattern qui consiste à forcer le choix d’un produit avant même d’avoir parlé du besoin du client. Hop ça c’est offert.
L’anti-pattern «Net Negative Producing Programmer» est le fantasme qu’en augmentant le nombre de développeur, la productivité va augmenter. Et bien pour certaines équipes, Neal explique qu’en virant 2 ou 3 personnes, parfois la productivité augmente de 30%. Radical mais pas faux.
L’anti-pattern «Boat Anchor» est assez marrant. C’est ce bon vieux module que vous vous trainez, cette compatibilité avec le client qui n’a toujours pas mis à jour son produit, et qui comme une ancre de bateau, vous freine énormément.
L’anti-pattern que je préfère et qui a bien fait rire la salle «The Death by Planning Anti-Pattern». C’est ce pauvre chef de projet qui passe sa vie devant Microsoft Project, et qui termine par une dépression car son outil ne gère pas l’imprévu, et qu’il passe son temps à remettre son planning à jour. Planifier c’est prévoir, pas prédire (ça c’est de moi, Nicolas Martignole)
Il passe ensuite quelques autres patterns, j’ai noté «les Poulets élevés en batterie», «L’Homme des Cavernes Congelé» et un petit dernier pour rigoler «The Rubick’s Cube». L’anti-pattern du Rubick’s cube consiste à inventer des problèmes qui n’existent pas encore afin ensuite d’en proposer une solution, forcément la meilleure. Essayez, cela marche avec OSGi et SOA par exemple.
Alors que faire ? Il continue en prenant l’exemple d’un client qu’il a rencontré. Les départements de ce client échangent des messages dans des enveloppes avec des contrats papiers. Le problème est que les enveloppes coûtent beaucoup d’argent, et qu’il y a des mélanges des messages entre les départements. Alors arrive un gros cabinet, que l’on appellera «Accentué» et qui propose une solution SOA. Celle-ci vise à dématérialiser l’échange des documents et à tout faire au format électronique. 1 millions d’euros, 2 ans de projet prévu avant que la solution ne soit prête. La DSI voyant cela s’inquiète et demande conseil à Neal. Il propose après 3 jours d’audit de remplacer les enveloppes grises par des enveloppes de couleur pour chaque département…. Et le client était content, la solution de dématérialisation ne répondait pas à son besoin, qui était de réduire les erreurs de tris. Pensez-y la prochaine fois.
Cela lui permet de revenir à ce qu’il appelle «l’accidental complexity». Celle-ci peut littéralement tuer une compagnie ou un département si nous ne sommes pas plus courageux et intelligents. Les responsables présents dans la salle écoutent poliment, le BlackBerry dans la main. J’espère que le message sera passé.
Il parle ensuite du management qui a évolué, ce qui recoupe la présentation d’Alain Buzzacaro dont je vous parlerai un peu plus tard. Les nouveaux managers sont souvent des anciens Geeks, des anciens ITs. Et personne n’ose dire qu’ils ne sont pas bons. Cela provoque des problèmes humains, on a inventé l’Agilité pour que cela fonctionne mieux, mais il y a bien un problème derrière tout cela : de bons geeks ne font pas forcément de bons managers.
Quelques slides plus loin, il explique le fonctionnement des éditeurs de logiciels. On pense à Oracle et IBM. Aujourd’hui vous, les gens qui font du Java, vous êtes comme les explorateurs et la ruée vers l’Or au 19eme siècle aux USA. Et les éditeurs ont bien compris ce qu’il se passait, ils sont les Levi Strauss des temps modernes. Je m’explique.
Levi Strauss s’est installé à San Francisco. Il a vite compris que plutôt que de creuser et de se salir les mains pour trouver un hypothétique nugget, il est plus intéressant de fournir les meilleurs pantalons aux chercheurs d’or, et donc de se faire beaucoup d’argent. Les éditeurs ont donc tout intérêt à ce que vous soyez les mains dans le camboui pendant qu’ils lustrent la carrosserie de leur Mercedes…
«With great complexity, came great power». Un système simple et transparent ne donne pas assez de pouvoir. Un bon gros système bien opaque et compliqué, donne beaucoup de pouvoir. Si vous ne voulez pas vous faire enfermer par un vendeur, prenez un système simple et ouvert.
La complexité accidentelle ou volontaire génère donc de l’argent. Mais moi, en tant que développeur, comment puis-je changer le monde et proposer autre chose ? Il nous parle alors comme à des enfants : pensez-vous que le business va tolérer les caprices de la DSI encore très longtemps ? Vous ne pensez pas qu’un jour, la récréation sera terminée et que vous devrez peut-être ne plus faire ce qu’il vous plaît ?
Prenez Toyota aux USA. Leurs voitures étaient moins chères et de meilleur qualité. Ils ont dépassé Ford ou GM. La qualité était meilleure, et maintenant le prix est même plus élevé que les constructeurs américains, car les consommateurs ont conscience d’acheter de la qualité…
Il parle ensuite de la Chine et de l’Inde, ce qu’il appelle Chindia. Quelques chiffres font peur : 1% des Indiens c’est déjà 11,3 millions de personnes… 0,1% des indiens avec un niveau Bac+5, c’est 1 millions de personnes, soit 2 fois la population des informaticiens en France estimée à 500 000 selon le Sintec. Alors que l’on parle moins d’Inde et de Chine pour nous ne signifie pas que nous sommes en sécurité. Il y aura un changement, on ne sait pas quand il arrivera, mais il sera là demain.
Il parle ensuite du Manifeste Agile, en expliquant que les personnes qui l’ont rédigé ont raison. Nous devons apprendre à changer rapidement, à revoir notre méthode de travail et à virer ce cycle en cascade qui doit mourir.
Pour conclure il nous laisse quelques conseils pour la suite de notre carrière :
Comprendre rapidement les lois de l’entreprise où vous travaillez, retirer les obstacles qui vous causent des soucis, arrêter les managers qui vous font faire n’importe quoi. Soyez responsable.
Pensez à vous-même, soyez critique comme Galilée. Ne pensez pas que cette solution aujourd’hui sera toujours pérenne dans quelques années. Pensez à vous-même en investissant du temps pour apprendre, ne croyez pas que vous savez, vous ne savez rien. Lisez, discutez, rencontrez, faite de l’amélioration continue. Sinon vous êtes mort.
Faites des choses qui… marchent.
Lisez le manifeste Agile et regardez comment fonctionne une équipe Agile. Soyez critique et adaptez les idées à votre entreprise.
Il termine en disant que le prix d’une chose est différent de la valeur. Ne pas facturer et venir se faire aérer les neurones à l’USI a un prix, je retiens surtout que la valeur de ce que j’ai entendu est bien plus importante, et je ne regrette pas cette matinée.
0 no like
Alexandre Adler a cité ce chiffre un jour (il y a 2-3 ans) : la Chine « produit » un million d’ingénieurs par an.
On aura l’air fin quand les docs de JBoss seront seulement en Chinois