Profile cover photo
Profile photo
Freddy Mallet
Co-Founder of SonarSource and Product Director of the SonarQube Ecosystem.
Co-Founder of SonarSource and Product Director of the SonarQube Ecosystem.

Freddy's posts

Post has shared content
Writing a book is a journey. At the beginning of the journey, you mostly know where you want to go, but have only vague notion of the way to get there and the time it will take. I’ve finally released the paperback version of Integration Testing from the Trenches on Amazon and that means this specific journey is at end.

The book starts by a very generic discussion about testing and continues by defining Integration Testing in comparison to Unit Testing. The next chapter compares the respective merits of #JUnit   and #TestNG . It is followed by complete description on how to make a design testable: what works for Unit Testing works also for Integration Testing. Testing in software relies on automation, so that specific usage of the #Maven  build tool is described in regard to Integration Testing – as well as #Gradle . Dependencies on external resources make integration tests more fragile so faking those make them more robust. Those resources include: databases, the file system, #SOAP  and #REST  web services, etc. The most important dependency in any application is the container. The last chapters are dedicated to the Spring framework, including #Spring  MVC and #JavaEE  .

In this journey, I also dared ask +Josh Long  of Spring fame and +Aslak Knutsen team lead of the #Arquillian  project to write a foreword to the book – and I’ve been delighted to have them both answer positively. Thank you guys!

I’ve also talked on the subject at some JUG and European conferences: JavaDay Kiev, Joker, Agile Tour London, and JUG Lyon and will again at JavaLand, DevIt, TopConf Romania and GeeCon. I hope that by doing so, Integration Testing will be used more effectively on projects and with bigger ROI.
Should you want to go further, the book is available in multiple formats:

- A paperback version on #Amazon  for $49.99 (
- Electronic versions for Mac, Kindle and plain old PDF on #Leanpub  ( The pricing here is more open, starting from $21.10 with a suggested price of $31.65. Note you can get it in all formats to read on all your devices.

If you’re already a reader and you like it, please feel free to recommend it. If you don’t, I welcome your feedback in the comments section. Of course, if neither – I encourage you to get a book and see for yourself!

Post has shared content

Post has shared content
Call for paper pour la soirée Anniversaire de Janvier !

La session de Janvier, toujours spéciale, sera l'occasion de fêter l'anniversaire du GenevaJUG. Et comme tous les ans, il y aura du gateau :-)

Cette année, nous avons décidé de vous mettre à l'honneur, vous qui venez si nombreux chaque mois et qui faites toute la richesse de notre communauté !

Nous vous proposons donc une soirée dont vous serez les héros en nous présentant les sujets que vous voulez sous forme de Quickies de 15''

Proposez nous donc vos sujets: outils, techniques, méthodologies, ... au travers de ce Call For Paper et nous selectionnerons 6 d'entre vous pour cette soirée exceptionnelle !

Pour proposer votre talk, suivez ce lien :

Post has attachment
The goal of a CI environment should be to make master branches unbreakable and not to provide a quick feedback when the master branches are broken.

During #devoxx  we had some passionate discussions about CI environments. Those discussions started after the reading of "How Google Test Softwares".

What's the current goal of most CI environments ? Notifying you as quick as possible as soon as some master branches have been broken ? With such approach, it's ultimately the responsibility of any developer before pushing some changes into a master branch to make sure that those changes don't break anything : compilation, unit tests, integration tests, ... whereas we all know that :
- The local developer environment is not reliable for such kind of validation
- This can highly impact the developer productivity (what to do when integration tests requires 3 minutes to be executed and consume 100% of the CPU time ?)
- This is a stressful approach for the developer as whatever is the effort provided, the risk to break the build always exists.

Of course, as soon as the build is broken, this becomes the top priority of the developer to fix what he has broken but it's already too late and this is again stressful and counterproductive. 

In fact a paradigm shift should occur : whatever the developers are doing, the master branches should be unbreakable. In other words : the CI environment should prevent developers from pushing some changes in the master branches which breaks the build.

If my understanding is correct, this concept is already in place at Google and a CI engine like Team City provides the required feature to "almost" support such approach when feature branches are used and when Team City is configured to automatically create some new jobs when a feature branch is started :

Of course, the impact on the CI environment can be huge as this leads to highly increase the number of validations done by the CI environments (close to the number of commits) but this definitely worth the price. 

Post has attachment
What's the dream sustaining your project development ?

I was a bit disappointed two days ago after the keynote about Dart at #devoxx . Indeed 2 years ago I was thinking that this project might revolution our future as some other languages did in the past. To be honest I'm still thinking that this project has a great "revolution" potential. But what did I learn during this keynote ? ... absolutely nothing that I didn't already know. Google engineers are so well driven by this culture of "fast failure, experimentation, evolution, ..." that they don't want to speak about  something that might never happen. Of course they don't know what the Dart environment will be in 2 years the same way I don't know what SonarQube will be in 2 years but banning any even light reference to this initial dream sustaining the development of the Dart environment was a mistake. 

The only answer I got to this fundamental question via Twitter was "More productivity, more performance, more happy developers!". Am I really so stupid ? :) 

Happily +Alexis Moussine-Pouchkine  did an interview just after the keynote and when you ask some good questions, you might sometimes get some interesting answers : Dart 1.0 interview with Lars Bak and Kasper Lund at Devoxx 2013

Google engineers, don't forget to make the community dream. You're sometimes so convinced by what you're doing and what you're going to achieve, that you might start considering all other developers as basic "consumers".  And keep doing this great job around #dartlang  

Post has attachment
Prédictibilité, ce mot si ambigu...

La semaine dernière j'avais la chance d'assister à dont SonarSource était l'un des sponsors (Merci encore à Dimitri Baeli pour son invitation). J'ai eu l'occasion d'assister à plusieurs présentations de qualité dont celle de Yannick Quenec'hdu "La prédictibilité avec Kanban, comment je tiens mes promesses"

Cette présentation de Yannick était vraiment excellente mais 2 messages passés durant cette présentation tiennent à mon sens au mieux d'une maladresse et au pire ... bon restons en à la maladresse. 

La première porte sur ce fameux mot "prédictibilité". En langage agile, la prédictibilité porte sur la capacité à maintenir dans le temps une vitesse de "delivery" et par voie de conséquence à pouvoir anticiper sur au grand maximum 2 mois ce qui va sortir du tuyau d'un point de vue fonctionnel. Le problème c'est que pour un manager IT, la prédictibilité c'est tout autre chose :  c'est la capacité à garantir qu'un projet d'une duré estimée d'1 an de réalisation va bien sortir dans les temps et avec le périmètre escompté. Durant la présentation, le mot prédictibilité n'a jamais été défini et malgré une question en fin de présentation, l'ambiguité n'a jamais été levée. Yannick, de quelle prédictibilité parlais-tu ?

Deuxième message: sur un projet de développement informatique et sous entendu quelque soit la nature du projet informatique, on peut arriver à un niveau de prédictibilité avec une variance maximale de 2%. En gros, à partir du moment où le processus est bien en place et parfaitement maitrisé, il n'y a aucun mur qui résiste. Autant je peux entendre ce message pour des développements à complexité faible à moyenne (sous entendu pour de l'informatique de gestion) autant pour des développements complexes ou requiérants un haut niveau de créativité, l'idée me semble plus que très dangereuse. Ou alors il est temps d'aller voir Microsoft et Oracle pour leur expliquer comment procéder pour tenir leurs délais sur les releases de Windows et de Java. 

L'agilité est né d'un constat : la prédictibilité est un graal donc oublions là !


Fin des 20% de temps consacré à l'innovation chez Google, pourquoi  crier au loup ? Tout le monde s'accorde à penser que soutenir un effort d'innovation est un défi hautement complexe et permanent. Innover se résumerait-il à une recette de cuisine à un élément qui s'appliquerait à tout le monde et de tout temps: allouer 20% de temps libre à tous les collaborateurs pour faire de l'innovation ? 

Post has attachment

Post has attachment

Scrum et le fantasme de l'auto-organisation

Dans sa définition et sa compréhension la plus courante, le principe d'auto-organisation Scrum tient heureusement du pur fantasme. Pour en savoir un peu plus sur ce principe d'auto-organisation, il vous suffit de prendre le premier consultant Agile en herbe qui vous passe sous la main et de lui poser la question 

Vous: "En quelques mots, ça consiste en quoi ce principe d'auto-organisation dans Scrum ?"

Consultant: "Une équipe Scrum est une petite équipe pluridisciplinaire, autonome, sans hiérarchie interne et auto-organisée. Ce principe d'auto-organisation est au coeur de la méthodologie pour permettre à l'équipe de s'adapter en continue aux changements."

Vous, grand crédule que vous êtes: "Ok, mais concrètement chez moi comment je fais pour mettre en oeuvre Scrum et adopter ce principe d'auto-organisation ?"

Lui: "Après des années de fonctionnement dans des structures classiques de management pyramidales, faire le virage va prendre du temps. Il te faut donc intégrer un ScrumMaster qui va progressivement amener l'équipe à maturité."

Vous: "Désolé d'être un peu lourd, mais ça marche comment ce principe d'auto-organisation ?"

Lui: "Commence par adopter les pratiques Scrum (stand-up, retrospective de sprint, ...), intègre un bon ScrumMaster et tu vas voir que la mayonnaise va prendre. D'ailleurs si ça prend vraiment bien tu verras qu'au bout d'un certain temps la présence d'un ScrumMaster ne sera peut être même plus nécessaire."

Vous: "Désolé de devenir très lourd, mais ça marche comment ce principe d'auto-organisation ?"

Lui: "Tu viens de passer 10 ans dans une boîte au mode de management très conservateur, il faut faire un acte de foi et avoir le courage de mettre un pied dans l'inconnu"

Vous: "C'est ça, prends moi pour un con!"

Et vous avez raison, on nous prend vraiment pour des cons. Le principe d'auto-organisation Scrum aux relents quelque fois vaguement humanistes est en fait une mécanique avec des rouages parfaitement connus, relativement intelligibles et qui doivent être compris par tous. 

Après plus d'une décennie de pratique approximatives, j'en suis arrivé aux conclusions suivantes :

1- Une équipe Scrum sans ScrumMaster c'est un fantasme, disons que c'est comme une fille sans cheveux pour paraphraser Nabila.
2- Une équipe Scrum c'est une équipe qui évolue avant tout dans un cadre extrêmement rigide : sprint, stand-up, backlog, rétrospective, réunion de planification, ... En gros c'est comme un musicien à qui vous dite : "En concert, tu vas pouvoir te lacher, tu vas partir en impro mais commence par maîtriser à la perfection et de manière presque maladive la partition suivante".
3- Ce cadre auquel on ne peut se dérober va offrir rapidement quelque chose de précieux : le feedback. Mais ce feeback va être dans 90% des cas douloureux ou disons contrariant (ex: on avait dit qu'on le ferait en 2 jours, nous venons de consommer nos 2 jours et ce n'est pas terminé, pourquoi ?). comme tout feedback, surtout négatif, il est toujours possible de se mentir à soi-même en l'ignorant. Le principal rôle du ScrumMaster est précisément ici : c'est en continue de mettre le doigt là où ça fait mal pour AMENER l'équipe à prendre des décisions d'ajustement très rapidement. Enlever le ScrumMaster d'une équipe qui fonctionne à plein régime et normalement au bout de 3 mois, elle va partir en sucette.

Donc pour un gars qui vient de passer 10 ans dans une structure de management IT classique, Scrum c'est quoi ?
1- Un cadre de conduite de projet beaucoup plus rigoureux (j'irai même jusqu'à dire professionnel quand on y ajoute les épices XP et Leans) que ce qu'ils ont connu jusqu'ici
2- Une capacité à identifier les problèmes beaucoup plus rapidement (fonction essentielle du ScrumMaster même si bien entendu tout le monde doit se sentir investi de cette mission)
3- Des prises de décisions collectives pour répondre à ces problèmes (là où avant ces décisions étaient prises de manière unilatérale par monsieur le petit chef). Et là encore le ScrumMaster a un rôle primordial à jouer pour faire accoucher l'équipe. 

Bref, tout cela c'est de la très belle mécanique qui s'appuie sur une forme d'intelligence collective et inutile d'en appeler en la foi en l'homme, à Che Guevara ou au tréfond de la nature humaine pour en justifier le bon fonctionnement. 
Wait while more posts are being loaded