Retour sur nCrafts 2016

Souvent quand on essaie d’expliquer ce qu’est le software craftsmanship, on a du mal à synthétiser les idées qui définissent ce mouvement. Après réflexion, il s’avère que la conférence nCrafts à elle seule nous donne un bel aperçu :

DDD, BDD, TDD, code quality, functionnal programming, craftsmenship, machine learning and much more… It´s all there at #nCrafts

— Biarnès Adrien (@biarne_a) May 13, 2016

Cette année était encore un excellent crû. Dans cet article nous vous proposons un aperçu de ce que vous avez pu manquer (ou pas si vous avez eu la chance d’y participer) durant ces deux jours. Il pourra également vous servir de grille de lecture des talks les plus intéressants de notre point de vue.

Agile experiments in machine learning – Mathias Brandewinder

Mathias Brandewinder nous a parlé de son expérience dans l’utilisation d’un langage typé (F#) pour un projet machine learning (ML) en lieu et place des langages traditionnels de scripting (python, R, …). L’objectif était de trouver la pertinence des paramètres de recherche du site homedepot.com sur une période allant de janvier à avril 2016. Les résultats sont consultables en ligne.

Même si le ML est un sujet passionnant, on se trouve habituellement dans une situation où les données ne sont pas suffisantes et rarement complètes (pas les même colonnes dans tous les échantillons). Le code écrit est très difficile à maintenir et à tester de manière unitaire; ce qui donne une couverture de tests très limitée. Enfin, il y a rarement une exécution en parallèle des modèles de prédiction.

Pour résoudre ces problèmes de manière effective, Mathias propose de :

• S’inspirer de ce qui est déjà fait par la science ! C’est-à-dire, à partir d’une ensemble d’observations, faire des expériences sur le modèle pour évaluer des hypothèses.
• Suivre des pratiques utilisées dans l’agilité.
• Utiliser un langage typé.
• Utiliser un cache pour stocker les prédictions déjà faites.

En théorie, c’est le chemin à suivre. Cependant, cette approche est toujours limitée par des modèles dont on ne connait pas a priori les features qui vont améliorer la prédiction. De plus, l’évolution rapide inhérente à ce type d’expérience génère un couplage fort dans l’implémentation des différents composants.

Il a donc proposé un modèle générique inspiré de la programmation fonctionnelle qui peut être appliqué à n’importe quel projet de ML :

[scala gutter= »true »]type Observation = {data1: String; data2: Int; AnotherData: String}
type Relevance: float
type Predictor = Observation -> Relevance
type Feature = Observation -> float
type Example = Relevance * Observation
 
type Model = Feature[]
type Learning = Model -> Example[] -> Predictor[/scala]

On peut noter que :

• Un typage fort du modèle d’entrée (classe Observation, mappée la plupart du temps depuis un fichier CSV).
• Une feature est une fonction qui va transformer d’une certaine manière l’échantillon et va donner comme résultat une représentation numérique.
• Notre modèle est un ensemble de features.
• La prédiction est l’application de mon algorithme d’apprentissage.
• L’apprentissage permet de passer d’un modèle vers une prédiction.

No estimates: how you can predict the release date of your project without estimating – Vasco Duarte

Cette présentation de Vasco Duarte porte sur le mouvement #NoEstimates sujet à propos duquel il a publié un livre.
Partant du principe que, dans nos sociétés occidentales, le temps est un aspect critique de nos vies, passer du temps à estimer nos backlogs est-il une chose pertinente et utile ?

Rappelons ce qui se cache derrière le mouvement #NoEstimates. Au lieu d’estimer chacune des stories de votre backlog pour prévoir ce que l’équipe pourra délivrer dans le futur, on se base uniquement sur le nombre de stories développées via la vélocité de l’équipe.

Pour que cela fonctionne il faut respecter certaines règles :

1. Les stories d’un projet doivent être découpées de manière verticale : la story une fois finie doit apporter immédiatement de la valeur métier.
2. Le temps de développement d’une story doit être relativement court : sur un sprint de deux semaines, on parle de stories dont le temps de développement dure au maximum une journée.

D’accord, mais est-ce que cela fonctionne ?

Vasco Duarte a pu nous fournir des comparaisons tirées de réels projets et les faits sont là : sur un projet de 50 sprints, au bout de 3 sprints on obtient 20% d’erreurs en estimant, et seulement 4% en comptant uniquement le nombre de stories. Au bout de 5 sprints, les estimations sont toujours à 13% d’erreurs, alors que la fiabilité en No Estimates ne change pas.

Quoi qu’il en soit, Vasco Duarte nous invite surtout à essayer et expérimenter par nous-mêmes afin de nous faire notre propre opinion.

Product vs Craft – Juan Delgado

Juan Delgado nous propose avec ce talk un sujet qui pourrait paraitre controversé dans une conférence dédiée au software craftsmanship : doit-on systématiquement écrire du code propre ?

À travers différents exemples tirés de son expérience, Juan nous invite à ne pas systématiquement se focaliser sur le code le plus propre et le plus testé possible. Il préconise de trouver le bon niveau d’effort à produire maintenant (délivrer la fonctionnalité) et plus tard (maintenance) pour satisfaire son client.

Par exemple, il lui est arrivé de développer un jeu de labyrinthe avec des effets d’optique dont l’attrait graphique est tel qu’on pourrait prendre une capture d’écran et l’afficher en poster sur le mur de son salon. Ainsi le focus a été clairement donné sur cet objectif durant le premier sprint. Il lui a semblé que si le jeu avait eu besoin de proposer un formulaire de connexion dès la première itération, il pouvait clairement produire quelque chose de peu attirant graphiquement dans un premier temps. C’était le compromis qu’il s’était imaginé. Or le client s’est tout de suite focalisé sur ce défaut, occultant totalement l’objectif primordial de ce jeu.

On voit donc que la notion de qualité est relative au contexte. Comment alors en trouver une définition satisfaisante ? Juan propose ainsi la combinaison de deux notions :

1. l’exactitude : mon programme ne doit pas produire de résultat faux.
2. la capacité à ajouter de nouvelles fonctionnalités ou d’améliorer l’existant de manière constante à moyen terme.

Un autre exemple de curseur différent autour de la qualité d’un projet informatique lui a été inspiré d’un article :

hey #nCrafts post about the right way of building software: https://t.co/adXVMTURM4 and putting software in mars: https://t.co/29G7s5IwLX

— Juan Delgado (@wadus) May 13, 2016

• curseur élevé : VMWare avait besoin de donner des estimations fiables et un logiciel hautement qualitatif car ses clients étaient de grosses structures habituées à des cycles prédictibles.
• curseur bas : au démarrage de Facebook, Marc Zuckerberg avait un avantage sur le marché des réseaux sociaux car il avait de l’avance. Stratégiquement il était préférable d’aller très vite pour conserver cette avance.
• curseur maximum : Mars Science Laboratory ou comment lancer une jeep scientifique sur Mars avec un ping de 10 minutes.

En conclusion : la qualité n’est pas intrinsèque car elle dépend du contexte.
Voyant que la salle n’a pas tant réagi que ça à ses provocations sur la qualité, Juan a terminé la session avec des citations de tweets (parmi lesquelles se cachent les siennes) :

• « les développeurs doivent résoudre des problèmes : écrire du code pour écrire du code ça n’a aucun sens ».
• « les développeurs doivent absolument être alignés avec le client ».
• « c’est acceptable d’écrire du code affreux si ça aide tes utilisateurs (améliorations de la performance, outils annexes mais utiles) ».
• « parfois on n’a pas envie de passer son temps à monter une intégration continue ou du déploiement continue ».

Ces petites piques nous rappellent que ce sont nos clients qui paient nos salaires et qu’il faut donc prendre le temps nécessaire pour délivrer un produit avec la qualité attendue.

Beyond flux: going full cycle with functional reactive programming – Clément Delafargue 

Dans ce talk, Clément nous a partagé son expérience et notamment sa frustration avec les bibliothèques de développement d’applications web.

Il a commencé, comme beaucoup de gens, à faire des sites avec du vanilla Javascript, puis du JQuery et a vécu l’arrivée des frameworks permettant de faire du « two-way data binding ».
Les choses se sont améliorées, mais très souvent, les frameworks deviennent compliqués à gérer.
React (avec ou sans implémentation Flux) donne un flux uni-directionnel et cela améliore vraiment la situation. Mais il faut quand même pas mal de boilerplate pour construire des applications d’un taille raisonnable.
De plus, la déclaration des actions dans les vues les rendent complexes de par le passage des fonctionnalités dans la hiérarchie des composants.

Il propose alors une alternative pour améliorer tous cela – le Reactive Functional Programming.
Avec RxJS, le DOM devient Observable, les vues ne lancent plus des actions (IoC) et Cycle.js propose le pattern Model View Intent pour compléter la boucle et connecter le tout.

Hello #MVI #nCrafts @clementd pic.twitter.com/jhkNy7pGOz

— Peter Önneby (@poenneby) May 12, 2016

Clément rajoute que l’API de RxJS est tellement riche que cela peut en effrayer certains. Il ne faut pas hésiter à l’expérimenter car c’est une bibliothèque très puissante.
Nous allons continuer de suivre les avancements dans ce domaine en constant changement.

Interviewing domain experts: heuristics from the trenches – Cyrille Martraire

« Communication usually fails, except by accident. » Professeur Osmo Antero Wiio -1978.

BDD, DDD et consorts: le métier est partout et la communauté comprend petit à petit que l’appétence au domaine soutenu est indispensable.
Oui mais, parler aux experts est difficile de par plusieurs facteurs:

• Leur temps est généralement compté, il faut éviter de le gaspiller.
• Cela demande de la curiosité pour atteindre un niveau nous permettant d’échanger plus efficacement (lectures, travail à la maison).
• L’expert métier n’en n’est pas toujours un car il est parfois expert dans la complexité du logiciel existant (legacy) et parce que chaque personne se base sur des modèles mentaux tacites.

Pour nous en convaincre, Cyrille a donné l’exercice suivant à la salle: définir un pantalon en quelques mots.
Les définitions varient forcément selon les personnes et les questions qu’il nous pose par la suite nous le prouvent, aussi « stupides » soient-elles :

https://twitter.com/poenneby/status/730764893956214785/photo/1?ref_src=twsrc%5Etfw

Pour arriver à une communication bi-directionnelle efficace, Cyrille nous a partagé ses conseils et heuristiques.

1. Arriver avec un aperçu du métier, un vocabulaire de base et une liste de questions pour être crédible.
2. Ne pas négliger la prise de notes:

1. Veiller à ne pas perdre d’information et à ne pas modifier les termes.
2. Faire de l’écoute attentive. Cyrille parle de safari de mots, à la recherche de nouveaux termes, de synonymes, d’émotions, d’hésitations.
   Il propose une légende simple pour ce faire ce qui permet de ne pas interrompre la conversation tout en se donnant la possibilité de la relancer ensuite autour d’un nouveau mot ou synonyme.
   Les cartes de connaissances peuvent également répondre à ce besoin.

• Ne pas hésiter à proposer des choses pour faire avancer la conversation (même des exemples stupides, pour contrer les modèles mentaux tacites).
  1. Retourner coder est une excellente manière de trouver d’autres questions pour la prochaine interview (itérations). Cela évite aussi les mauvaises surprises.
  2. Ne pas hésiter à faire des parallèles avec d’anciennes expériences, même si elles n’ont rien à voir.
• Trainer à la machine à café (sic); c’est un bel endroit pour apprendre (discussions informelles).
• Montrer aux experts que l’on n’est pas là pour leur prendre leur job. Toujours faire valider, même si l’on est sûr de soi.

Ce talk nous a ainsi semblé d’une grande valeur et nous appliquons d’ores et déjà certains des points ci-dessus dans notre travail quotidien.
Il nous semble essentiel pour quiconque souhaite délivrer des logiciels plus proches des besoins utilisateurs, du développeur à l’analyste fonctionnel.

Beyond patterns & principles : writing good code – Matthias Noback (@matthiasnoback)

Dans cette présentation, Matthias fait un tour d’horizon sur les bonnes pratiques en programmation objet et établit leurs correspondances avec les principes les plus connus commes les principes SOLID :

– Un service injecté doit ne contenir qu’une seule méthode publique, et ce service ne doit pas contenir d’état. Cette classe Service correspond en fait à une fonction dans le monde de la programmation fonctionnelle. On respecte ainsi les deux principes Single Responsibility Principle et de Interface Segregation Principle qui font partie des principes SOLID. Dans un tel service, les effets de bords et la responsabilité deviendront plus explicites et les dépendances deviendront plus faciles à bouchonner (mock).

– On croise parfois du code consistant à vérifier l’état d’un objet pour savoir si l’on a le droit de l’appeler. Une meilleure approche consiste à refuser la création de tout objet incohérent. De cette manière, on obtient des objets dont il est plus facile d’avoir un raisonnement, plus facile à debugger et plus facile à refactorer. Cela mène au principe « tell don’t ask » qui évite l’effet « anemic dummy model ».

– Il faut favoriser l’immuabilité. Cela aide à la distinction entre l’usage et la modification de l’état. On peut ainsi passer des objets en paramètre et les utiliser sans s’inquiéter des conséquences.

– Les objets doivent communiquer entre eux avec des messages clairs. On ne doit pas mélanger récupération de résultat demande d’action. Ce qui est également connu sous le nom de principe CQS (Command Query Separation).

– Tout est objet, y compris votre application et votre système. Ils ont des états et des effets de bords (clavier, écran, mémoire, …). Les principes précédents s’appliquent donc à votre application.

Et le tout en image :

Mais aussi…

Comme il est difficile de résumer toutes les présentations que l’on a vu dans une conférence, voici un petit paragraphe pour mentionner notre intérêt à l’égard de certains talks desquels nous n’aurions pas eu le temps de faire un résumé mais que nous vous conseillons de regarder lorsque les vidéos seront disponibles sur le net.

The Long Road – Sandro Mancuso : C’était la keynote d’ouverture de NCrafts. Comme toujours, Sandro inspire et motive son assemblée. Si vous vous demandez comment diriger votre carrière ces prochaines années, ce talk est pour vous.

Rise of the Digital Hussars – Laurent Bossavit : En 15 minutes, Laurent explique qu’il travaille dans le public depuis un an et pourquoi malgré un tas d’inconvénients, c’est une expérience qu’il conseille aux autres.

The Art of Visualising Software Architecture – Simon Brown : En partant du constat qu’il est encore assez difficile de représenter l’architecture logicielle, entre génération de modèle UML trop complexe et schémas manuels immaintenables et incorrects, il présente un outil de sa création : Structurizr.

If the problem was the solution – Arnaud Lemaire : Dans ce quickie, Arnaud démontre l’importance de la formulation du problème dans sa résolution. Il parle avec humour de modèle gravitationnel, d’entropie, d’Einstein et de software design (entre autres !).