Après avoir lu un retour à chaud qui m'a semblé particulièrement peu représentatif de ce qui s'est passé à la QCon, j'ai réalisé combien un événement comme celui-ci pouvait-être perçu différemment en fonction des centres d'intérêt et même des compétences du participant (pouvant éveiller quelques susceptibilités sans doute). Étant donné le peu de retours en français, je me suis décidé à en faire un, même tardif sur la QCon 2010 à Londres, pour donner mon point de vu, également subjectif.

Premièrement, l'événement en lui même. Pour ceux qui ne connaissent pas c'est une conférence autour du développement logiciel, qui a lieu chaque année à San Francisco et à Londres. Cette année, ce qui avait attiré notre attention avec mes collègues, c'était la liste impressionnante d'orateurs de renom, inventeurs de langages, ou de concepts majeurs de développement :

  • Ralph Johnson : l'un des membre du Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides) qui a écrit un ouvrage qui a fait date sur la conception objet : Design Patterns
  • Martin Fowler : un pionnier et pilier de l'agilité, de la programmation, du refactoring, qui a créé la société ThoughtWorks. Il est également un auteur d'un grand nombre d'articles (voir sur son blog) très intéressants.
  • Michael T. Nygard : l'auteur notamment de Release It! qui est un livre lumineux sur l'administration pragmatique d'une plateforme web, et qui milite pour le rapprochement entre les développeurs et les opérations
  • Dan Ingals : l'inventeur du langage SmallTalk, langage objet, et qui a 40 ans d'expérience dans le développement logiciel
  • Joe Armstrong : l'inventeur du langage Erlang, langage conçu pour gérer la programmation parallèle en se basant sur le passage de messages entre processus légers.
  • Eric Evans : auteur de DDD, Domain Driven Design, une approche du logiciel axée sur l'ubiquité de langage entre les concepts métier et techniques.
  • Jim O Coplien : auteur de plusieurs livres sur le développement objet et C++
  • Dan North : père du Behaviour Driven Development et consultant chez ThoughtWorks pendant des années

Et encore bien d'autres. En voyant également les thématiques abordées (6 par jour, une par salle), comme Software Craftsmanship, Non-Relational DBs & Web Oriented Data, Dev and Ops: A single team, Functional programming, Irresponsible Architectures and Unusual Architects, The Concurrency Challenge, How do you test that?, etc, et en plus la proximité (Londres c'est à 2h40 en train), nous nous sommes dit que nous ne pouvions pas passer à côté. Nous y avons été avec JP, Merci Multimedia Business Services qui a joué le jeu et nous a payé la conf en formation.

L'événement a été vraiment à la hauteur de nos attentes : 700 développeurs, plus de 100 orateurs, lieu pratique, agréable, en face de Westminster, des présentations vraiment intéressantes, des participants et orateurs simples d'accès. Pour faire le français de base, je pourrais même ajouter qu'à midi nous avons été très bien nourri, pourtant dans une conf d'informaticiens à Londres nous aurions pu en douter :). Dans les choses sympa, je retiens les écrans graphiques avec les tweets sur la QCon qui s'affichent avec des réactions live des participants qui lancent des micro-débats avec des personnes suivant la conf sur twitter. Pratique aussi les prises partout dans les salles au sol sous de petites trappes pour mettre les laptops en charge.

Sur le fond, ce que j'en retiens :

- l'adoption des tests automatiques : cf les tracks « how do you test that », avec les tests asynchrones, de charge, et les nombreux sondages lors des confs sur les tests auto et le TDD qui voyaient beaucoup de mains levées. C'est à dire que l'approche favorisée est empirique versus déterministe. Le développement logiciel est très complexe par exemple les couches utilisées lorsque l'on développe sont nombreuses (7 couches réseau pour la partie communication, les couches liées à l'exploitation de la machine, les couches graphiques, etc.). La démarche est donc : je ne sais pas prévoir avec certitude ce qui va se passer, alors je vais prouver au minimum que le programme fait bien ce qu'il est sensé apporter comme valeur au client par des tests, unitaires, d'intégration, fonctionnels, de charge. Je n'ai pas confiance non plus dans la stabilité de ces fonctionnalités à l'épreuve des modifications futures du programme, alors je rééxécute les tests à chaque modification (commit) de la base de code. Ensuite, je m'arrange pour que ce code puisse évoluer sans que cela ne représente trop d'effort (et donc de coûts pour le client). Alors je supprime le code qui ne sert pas, je supprime les duplications (pour ne pas faire plusieurs fois les mêmes choses), je renomme lorsque j'ai mieux compris les concepts. Ainsi, je fais émerger un design de l'application qui s'adapte au mieux aux évolutions du métier (diminution des couplages, ubiquité de langage, réduction des duplications).

- la nécessité dans l'avenir de travailler sur du code ancien. Je le comprends d'autant plus que ça fait 15 ans que je fais du développement logiciel, il m'est arrivé qu'à de rares occasions de partir « from scratch ». La majeure partie du temps c'était sur des applications existantes, 100000 lignes de code de C++ ici, 1 000 000 de lignes de code de C/C++ par là, 300000 lignes de code de java, 100000 lignes de Java/C++, voici les principaux projets sur lesquels j'ai travaillé. Ralph Johnson a fait une excellente introduction « Living and working with aging software » lors de la 2e journée. Il soulignait que lorsqu'un secteur industriel devient mature, il devient plus sensible au capital. A la fin du siècle dernier, c'était rapide, lors de l'émergence d'internet de devenir un acteur important (ce qui a provoqué cette fameuse bulle), à présent, pour aller marcher sur les platebandes d'amazon, ou google, c'est plus difficile. Car ils ont acquis un capital pendant toutes ces années. Quel est-il ? c'est le code, et Ralph Johnson ajoute « les structures sociales et techniques pour le comprendre ».

Cette nécessité évoquée dans plusieurs présentations (notamment dans le track software craftmanship), me fait penser que probablement vont se constituer 2 marchés dans le développement informatique : un marché axé sur la diminution des coûts qui serait ce qu'est le prêt à porter à l'industrie textile, avec une conception ouvrière du développement ce qui amène par exemple à la sous traitance (Inde, Chine...), qui produit des applications rapidement développées mais également endettées, avec des coûts importants de maintenance, et donc de faible durée de vie. Un marché axé sur la qualité, qui pourrait correspondre au "sur mesure" ou "haute couture" du textile, avec une conception de créateur artisan (dans le sens d'expertise du domaine), qui développe progressivement des applications durables et évolutives.

- l'efficacité des équipes intégrées : une seule équipe fait l'exploitation et le développement d'une plateforme de service. A partir d'une certaine taille, les entreprises de services (faisant de l'hébergement) sont souvent organisées en 2 silos : une partie des équipes font de l'hébergement (administration des machines, du réseau), l'autre partie développe les services. Dans chacun de ces silo, il peut exister des méthodes de travail différentes, des cycles différents, et cela abouti à une absence de partage de connaissance. Nous voyons les dérives en cas de pression, ce sont ceux que nous ne connaissons pas qui sont fautifs. Pour préciser en schématisant un peu, les développeurs font du code pourri, et les exploitants ne savent pas administrer une plateforme. A l'extrême cela peut mener à la catastrophe, ce que décrivait Michael T. Nygard dans sa présentation "When the Fur Flies: Dev and Ops Cooperation when the Worst Happens".
Michael Nygard y décrivait 2 projets auxquels il a participé, avec un environnement dans lequel l'absence de communication et de travail en commun avait mené des services à l'échec. Ces exemples sont dans son livre "Release It!". Julian Simpson ("siloes are for farmers : production deployments using all your team") et Sam Newman ("from dev to prod") de ThoughtWorks, ont donné ensuite des clés pour travailler dans des équipes intégrées :

  • binômage entre devs/op
  • respecter tout le monde
  • créer des ponts entre devs/ops : manger ensemble, aller boire des coups ensemble
  • même mécanismes de déploiement quelque soit l'environnement (y compris production)
  • créer de l'alignement : exemple ne pas séparer les responsabilités du build (dev) et du déploiement (ops)
  • les logs applicatives sont une ihm
  • séparation de la configuration extrinsèque de l'application des binaires (2 fois)
  • tester les scripts de déploiement en intégration continue

- importance de la scalabilité. Les plateformes (notamment web) évoluent énormément en terme de charge : nombre d'utilisateurs augmentent, les usages évoluent, moyens d'accès se diversifient (smart phones, ordi maison, portables, bureau), et les plateformes de services doivent s'adapter. La scalabilité d'une plateforme c'est sa capacité d'avoir des coûts linéaires en fonction de l'évolution de la charge. Par exemple, un service fonctionne avec 15 serveurs d'application pour 1 million d'utilisateurs uniques par mois, il "suffit" (je passe les problématiques réseau) d'ajouter 15 autres serveurs pour tenir 2 millions. C'est aussi le cas à une plus petite échelle pour les programmes de tirer parti des processeurs multi-cœurs. C'était ces problématiques qui étaient en filigrane lors des tracks de programmation concurrente avec des patterns pour la programmation concurrente par Ralph Johnson, et la présentation d'Erlang, langage orienté concurrence.

C'était aussi le sujet du track "pragmatic cloud computing" mais je n'y ai vu aucune conférence.

- la simplicité est à l'honneur, en remettant en cause les dogmes comme les modèles 3 tiers, l'immédiateté des retours aux utilisateurs, la programmation en couches (UI, services, métier, persistance, db), les bases de données relationnelles, l'utilisation du remoting etc. C'était les conférences du track "Irresponsible Architectures and Unusual Architects". Dan North y remettait en cause le mapping relationnel/objet en supprimant les bases de données, les portlets, maven, le remoting (faites du HTTP c'est simple et ça marche). Il voyait un pattern : nous créons des abstractions, les transformons en framework, ces framework deviennent la solution à tout, les utilisateurs du framework commencent à le subvertir, finalement d'autres manières de faire émergent.

Udi Dahan propose de faire une ségrégation entre les commandes (modifications du système, ou écritures) et les requêtes (présentation de l'information du système, ou lectures), en essayant de capturer l'intention de l'utilisateur. Il propose par exemple

  • de ne pas donner systématiquement un retour immédiat à l'utilisateur. Exemple quand vous commandez un livre sur amazon, il ne vous présente pas un résumé de la commande immédiatement, mais vous dit qu'il vous envoie bientôt un email de confirmation. C'est suffisant puisque de toutes façons vous recevez cette dernière au mieux 24h plus tard, et ça évite de charger le système en ajoutant de nombreuses requêtes de lecture
  • d'utiliser des queues asynchrones avec une prévalidation avant d'envoyer la commande
  • de montrer éventuellement de l'information qui date, en indiquant l'age des données
  • de découpler les écrans dans les IHM
  • d'utiliser des mécanisme d'abonnement/publication

Le track "non-relational databases & web oriented data" allait aussi dans ce sens. Nous avons plusieurs fois entendu des remises en causes des bases de données relationnelles (Dan North, Bryan Fink). Celui de Software Craftmanship même si c'était la présentation d'une façon de coder de type artisanat (cf le manifeste), était aussi très insistant sur la simplicité (de codage et d'attitude).

- le bon langage pour le bon usage. Nous avons eu des présentations techniques impressionnantes de "distillation de connaissances" :

  • de Dan Ingals avec son projet lively kernel, qui est une interface graphique en javascript/smalltalk
  • de Rebecca Parsons qui nous a montré en scheme comment faire en 40 lignes un parseur générique (elle a d'ailleurs précisé un "faites ça en Java et vous verrez" pas forcément utile au discours)
  • de Joe Armstrong sur Erlang, et aussi de Bryan Fink sur Riak, un sytème de stockage clé/valeur hautement disponible, scalable, avec tolérance de panne, développé en erlang

Bref, chacun de ces exemple est réalisable avec n'importe quelle technologie, mais ce qui en fait l'efficacité et la pertinence, c'est l'utilisation d'un langage adapté, à savoir ici : l'objet pour les interfaces graphiques, le fonctionnel pour le parsing, et le passage de message entre processus légers pour un système de stockage clé/valeur fiable et tolérant les pannes.

Désolé d'avoir été si long mais ces 3 jours étaient très denses. Peut-être le format "au fil de l'eau" est plus approprié dans ce cas...