Et voilà, ma deuxième expérience belge de Devoxx est entamée.

How To Do Kick-Ass Software Development

J’ai choisi cette présentation de Sven Peters d’Atlassian, car j’avais beaucoup apprécié sa présentation l’année passée sur 7 things to make a good team great. Il y présentait 7 trucs pour rendre une bonne équipe encore meilleure. C’est d’ailleurs lors de cette présentation qu’il m’est venue l’idée de mettre les Brown Bag Lunch à la SGCIB (via l’idée ”Feed you brain”), peu de temps avant que ce mouvement ne prenne de l’ampleur en France.

Sven s’est intéressé au film Kick-Ass, où une personne quelconque souhaite devenir un super-héros, juste en portant un costume. Forcément, au début il se fait dérouiller, mais persiste. Et c’est le message de Sven : se prendre des gamèles, mais toujours se relever.

Mais que souhaite t-on atteindre avec son équipe ?

• un meilleur software ;
• moins d’overhead ;
• un développement plus rapide ;
• des clients heureux ;
• des développeurs heureux.

Il y a quelques temps, la solution à tous les problèmes était l’agilité. Mais qu’en est-il en 2013 ? Le problème de toute méthodologie ou technologie c’est qu’au début c’est super, mais très vite les soucis commencent à surgir, jusqu’à s’apercevoir que cette solution ne résoud pas tous les problèmes (voir la Gartner Hype Curve).

Il faut toujours garder à l’esprit de construire la bonne chose (”Building the right thing”). Une idée est le ”Fake it til you make it”. Sven nous montre l’exemple à ne pas suivre avec le téléphone Kin de Microsoft. Censé être très adapté à la nouvelle génération, il fut un échec très retentissant, sorti de la vente à peine au bout de deux semaines, et aura fait perder plus d’un milliard de dollars à la firme !

A l’opposé, IBM a voulu tester une application de reconnaissance vocale. Plutôt que de développer un système complexe, ils ont triché en mettant une personne réelle dont le rôle était d’exécuter les tâches dictées par un cobaye. L’expérimentation n’ayant pas convaincue, il fut décidé que l’application réelle ne serait pas développée.

Passons à l’importance du feedback. Celui-ci doit répondre à trois critères :

• facile à trouver ;
• simple ;
• rapide à soumettre.

Il ne faut pas embêter directement les développeurs avec les feedbacks. Par exemple, pour l’équipe GMail, il y a 100 développeurs pour 425M utilisateurs. Imaginer que ce soit les développeurs qui traitent directement les feedbacks des utilisateurs. Le développement de l’application n’avancerait jamais. Cependant, tous doivent être conscients de ce qui ne va pas.

Chaque jour, l’équipe d’Atlassian se réunit 45 minutes pour revoir ces feedbacks et en faire quelque chose de personnel. De plus, chaque développeur passe une semaine par an au support de premier niveau, pour être en contact directement avec les problèmes des utilisateurs.

Autre point, ce qu’ils appellent le Developer on Test. Il s’agit de faire remplir le rôle de testeur aux développeurs. Pour cela, six astuces :

• Le training. Comment penser comme un testeur ?
• Faire du pairing entre un testeur et un développeur.
• Blitz Test : durant une journée, toute la compagnie - et pas seulement les développeurs et les testeurs - teste une nouvelle vesion.
• Définir des recettes de tests.
• Instaurere des sessions séparées : pendant une heure, deux équipes testent les mêmes choses, puis comparent leurs résultats.
• La chasse aux bugs : pendant une semaine, un développeur est dédié à la chasse aux bugs sur tous les éléments marqués comme Terminés.

Sven nous rappelle alors que “La qualité est la responsabilité de chacun”.

Sven passe ensuite sur le design. A Atlassian, les développeurs font aussi du design. Ils n’étaient pas forcément mauvais, mais cela avait tendance à partir dans tous les sens. Ce dont ils ont besoin, c’est de lignes directrices, de design guidances (les guidlines de design d’Atlassian).

Ils organisent également des workshops pour les développeurs.

Comme un développement complet requiert la collaboration de plusieurs départements, il est important de supprimer les frictions qui peuvent apparaitre entre eux.

Atlassian définit également des guidelines pour le développement. Ainsi, pour chaque tâche une branche est créée sur Git. Leur durée de vie est ainsi très courte (environ 2 jours). Puis, pour merger le code, ils passent par des push requests, ce qui fait que le nouveau code est revu et validé par ses pairs. Ce nouveau code n’est donc plus de la responsabilité d’un seul développeur.

Dernier point : l’automatisation. Le principe est d’échouer rapidement (Fail fast). 4 choses à retenir :

• Mettre à disposition les artifacts générés.
• Paralleliser les tests pour les accélérer.
• Avoir une stratégie de builds. Créer des couches de tests selon leur catégorie, leur intérêt.
• Toujours avoir un oeil sur les statistiques. Savoir par exemple ce qui prend du temps sur un build, pour être en mesure de l’accélérer.

Encore une belle présentation de Sven Peters.

Patterns, Shmatterns

Pourquoi cette présentation ? Tout simplement pour son orateur, Chet Haase. L’année passée, il avait aussi présenté un Quickie (The Future of Software Development Process Methodology Effectiveness) qui avait été un beau succès.

Encore une fois, la salle était comble. Chet Haase a cette fois-ci passé en revue un certain nombre de patterns et les a comparé avec ses propres patterns, ce qui en faisait quelque chose d’assez drôle.

Don’t use Git

A nouveau, Sven Peters sur la scène. Le titre de la conférence peut paraître provocateur, tant Git est utilisé partout (Atlassian a même Stash dans son catalogue, un gestionnaire de repositories Git). Mais cela est en fait une façon de promouvoir ce système de gestion de sources.

Sous le ton de l’ironie, Sven essaie de démonter les arguments qui font de Git un vrai succès. Git permet de travailler en mode déconnecté ? Mais c’est la fin du travail collaboratif ! Git rend les merges faciles et presque automatiques ? Mais le travail de merge sur SVN est une ôde à la cohésion d’équipe…

Bien entendu, tout cela n’est que prétexte pour montrer en quoi Git est supérieur aux anciens gestionnaires de sources comme SVN.

Efficient coding in IntelliJ IDEA

Nikolay Chashnikov est aux commandes pour nous montrer comment bien maitriser son IDE IntelliJ IDEA de JetBrains. Après pas mal d’essais ratés, je suis finalement passé définitivement sur cet IDE depuis un an, et clairement, je ne reviendrais pas en arrière. Mais je suis conscient de n’utiliser qu’une toute petite partie des capacités de l’outil. J’attends donc de cette session qu’elle me donne plein de bons conseils.

Hélas, je resterais sur ma faim. Une bonne première partie de la session montre surtout les capacités d’autocomplétion proposées par IntelliJ. Le reste est avant tout la découverte (ou non) d’un certain nombre de raccourcis claviers. Bref, pas grand chose à se mettre sous la dent, si ce n’est 2 ou 3 nouveaux raccourcis. C’est chez payé pour une conférence d’une heure !

Je pense que cette session peut être intéressante pour une personne utilisant Eclipse et souhaitant comprendre pourquoi IntelliJ est si puissant. Mais pour un utilisateur d’IntelliJ, même un non expert comme moi, peu d’informations à en tirer. Dommage.

Elastify your app: from SQL to NoSQL in less than one hour!

J’avais déjà assisté à cette présentation lors de Devoxx France 2013, toujours faite par Tugdual Grall et David Pilato. Je me suis dit que j’allais quand même y jeter un oeil pour mieux l’apprécier.

N’hésitez pas à relire mon résumé lors de Devoxx France 2013.

The Curious Case of JavaScript on the JVM

J’aime Java, j’aime le JavaScript. Je me dis qu’une session mélangeant les deux pourrait être intéressante. Je me décide donc d’aller voir ce qu’en dit Attila Szegedi. Il y était question de Nashorn, qui est l’implémentation d’un runtime JavaScript hautes performances sur la JVM.

En gros, on écrit du JavaScript mélangé à du Java - à moins que ce ne soit l’inverse ? A noter que Nashorn devrait être normalement inclus dans le JDK 1.8.

J’ai un peu de mal à voir l’intérêt de ce mélange, mais pourquoi pas. C’est aussi ce genre de chose qui fait la richesse de la plateforme de la JVM :)

Voilà une première journée déjà bien intéressante, j’attends avec impatience la deuxième fournée de conférences, qui s’annonce de belle qualité.