The (french) case against the NIH syndrome

Attention: les cascades de cette présentation ont été réalisées par des professionnels, n'essayez en aucun cas de les reproduire chez vous...

C'est en substance ce que j'aurai eu envie de lire comme commentaire de fin autour de cette très agréable soirée passée chez nos amis d'ABC Arbitrage, pour un meetup d'Alt.NET de haute volée, intitulé : "SOA et Service Bus" ce jeudi 3 octobre.

Pourquoi cela? parce que j'ai vraiment eu le sentiment ce soir là, d'avoir été complètement à contre-courant de l'enthousiasme général autour des messages délivrés par les speakers (mais il faut dire que l'excellente qualité de leurs présentations ainsi que leur état d'esprit très sympathique ont du aider). 

Mais avant de détailler ici les raisons de mon scepticisme, parlons d'abord des choses qui m'ont plues :

• Leur SOA pragmatique. En gros, l'important avec le SOA n'est pas d'utiliser tel ou tel protocole, ou tel ou tel format de message, l'important est déjà de penser son SI en terme de briques cohésives rendant des services avec un couplage lâche (le SOA apportant les mêmes bienfaits au niveau de l'architecture, que l'encapsulation au niveau de l'OOP)
• Leur découpage progressif et pragmatique de leur ancienne plate-forme monolithique en un modèle distribué et orienté service. On commence avec un service, on acquiert du feedback, de l'expérience ... et on continue petit à petit.
• Leur attention portée sur la réduction de la dette technique au fil de l'eau et des projets
• La cohérence de leur écosystème et de leurs APIs qui visent semble t-il la simplicité (l'approche "pit of success" qui est aussi une de mes marottes ;-) Le fait que cet écosystème cohérent facilite l'intégration et la productivité des nouveaux arrivants (à qui ils confient généralement l'implémentation d'outils pour compléter l'offre, comme première tâche)
• L'utilisation de produits open source, et leur "polyglot persistance", c.ad. de ne pas se limiter à une seule stratégie de persistance (i.e. SQL Server) en fonction de leurs besoins.
• La qualité de leurs supports et de leur présentations ce soir là. Très agréable et très efficace pour l'auditoire.
• L'état d'esprit positif, ouvert, dynamique et très sympathique de l'ensemble du crew ABC

Ca fait déjà pas mal de bonnes choses me direz-vous ;-)

Bon. Abordons maintenant ce que j'ai moins aimé:

• L'omniprésence des challenges techniques, et une absence quasi totale du métier dans leur discours. Je n'ai pas le souvenir d'avoir entendu parler de leurs utilisateurs, de l'interactions avec ceux-ci, des challenges qu'ils avaient à relever, etc. Du coup, cela a renforcé l'impression d'une équipe de DEV qui se fait un peu plaisir toute seule (et cohérente avec le NIH que j'aborderai plus tard). Je ne dis pas que c'est leur cas -pas de procès d'intention ici donc- je dis juste que cela a renforcé cette impression chez moi pendant leurs présentations. Car même si je kiffe la technique et apprécie particulièrement le mechanical sympathy, j'ai beaucoup de mal en revanche, lorsque celle-ci n'est pas pilotée par de vrais cas d'usages
• Le flou quant à la définition de ce qui peux justifier la création d'un service chez eux (quels sont les critères de création/d'ajout). Ce point, combiné à l'atrophie de la place du métier dans leur discours m'a presque donné l'impression qu'ils parlaient tout le temps de "services windows" et non pas de "services à portée fonctionnelle" (alors que ce devait être le cas à mon avis). Je pense que d'aborder un ou deux exemples concrets de ce qui était un service chez eux, aurait pu donner plus d'épaisseur et moins d'ambiguité à leur discours (en tout cas pour moi).
• La naïveté de certains choix : comme Cassandra pour une persistance "reliable". Car ce n'est pas parce que Cassandra est constitué en Cluster, qu'il est pour autant fiable et consistant (sur ce sujet, je vous invite à lire le récent post d'Aphyr qui explique tout ça, et à patcher vos versions de Cassandra au plus vite d'ailleurs, par la même occasion ;-)

Abordons maintenant ce que je n'ai pas du tout (mais alors pas du tout ;-) aimé:

• Pire que la justification, le discours d'évangélisation autour du Not Invented Here (NIH) syndrome (affublé ici de l'adjectif 'pragmatic') . Pour rappel, il s'agit de la tendance d'une entreprise ou d'une équipe, qui re-développe quelque chose qui existait déjà sous prétexte que cela n'a pas été conçu ou mise au point à l'intérieur de celle-ci. Que le contexte particulier d'ABC arbitrage (taille, budget, qualité de l'IT) les ai mené à faire tel ou tel choix d'architecture ou d'implémentation cela peut se comprendre (se discuter aussi, étant donné le côté quasi systématique de la démarche chez eux: hosting, déploiement, monitoring, middleware, ...). Mais promouvoir cette approche avec une certaine naïveté; j'ai été très, très mal à l'aise avec ce discours. Pourquoi est ce que je parle de naïveté ici ?!? Et bien c'est lié aux 2 autres points qui suivent:
• Le fait de minorer le coût total d'une telle entreprise (i.e. de faire croire à l'assistance que c'est simple, pas cher et rapide d'implémenter un middleware). En effet, implémenter une solution de messaging ne s'improvise pas, et ce n'est certainement pas en une seule fois que celle-ci sera mature et utilisable (et puis c'est du temps en moins passé à répondre aux besoins du business). Lorsque j'ai posé la question en séance sur le coût total de cette solution, c'est le coût initial qui m'a été donné (2 mois pour 4 développeurs si j'ai bien retenu). Et bien je gage moi, que le coût sérieux et total de la v1 (sur toutes ces années, et au fil de tout ces projets) n'a pas vraiment été pris en compte, lorsqu'il a été décidé de partir sur une implémentation de leur v2 (vs. acheter une solution du marché)
• L'absence totale de capacity management dans une telle entreprise (on parle du développement d'un middleware maison, tout de même!). Pour moi, c'était le plus gênant. En effet, comment savoir que l'objectif (de latences inférieures ou égales à la milliseconde, avec de la distribution de market data sur des 50aines de clients) est atteint  si on ne met pas en place des instruments de mesure concrètes ? Comment s'assurer qu'un affolement de la volumétrie des market data ne saturera pas totalement le réseau (ou la latence des publishers avant;-), étant donné la stratégie tcp-unicast choisie (vs. multicast), si on ne mesure pas ce qui se passe sur le réseau? En gros: comment savoir que toute l'activité de la boîte n'est pas mise en danger par certains choix d'architecture? Et bien, si on ne mesure pas : on ne peut pas savoir ! (sauf en le découvrant à nos dépens en prod --> j'aurais des dizaines de war stories à vous raconter sur ce sujet là...). Sur cette culture de la mesure qui me parait désormais indispensable d'avoir et de mettre en oeuvre, je conseille vivement l'excellente et très percutante présentation de Coda Hale: "Metric, Metrics everywhere")

En conclusion

Vous l'aurez compris, je suis beaucoup plus réservé sur le bilan très positif dressé par presque tout le monde du contenu de cette soirée. En état (et sans plus d'informations) je peux comprendre l'intérêt pour une société comme ABC arbitrage d'avoir eu recours à une telle stratégie de build systématique (étant donné la taille de la structure, et l'excellente qualité de ses développeurs), mais je trouverai très dangereux de généraliser cette approche à d'autres contextes (ce que je pouvais entendre en discutant le soir même avec les uns et les autres, ou en lisant certains retours très enthousiastes par la suite). Le plus gros risque avec cette approche NIH étant de perdre son énergie dans des combats annexes, et de ne pas se concentrer sur ce qui apporte véritablement de la valeur à nos utilisateurs (un travers contre lequel nous devons tous lutter, nous développeurs).

Pour ceux qui douteraient encore de la complexité d'une telle entreprise (i.e. développer son propre middleware low latency), je recommande la lecture de quelques documents produits par le Jimi Hendrix des middlewares, à savoir Todd.L. Montgomery (ça pour l'architecture, mais surtout ça pour l'implémentation).

En tout cas, et comme à son habitude, ce fut une excellente soirée ALT.NET, propice à de nombreux échanges et rencontres entre passionnés. 

Merci à Rui et aux gens d'ABC Arbitrage pour tout ça !