In the first part of this blog post, I explained the software craftsmanship bootcamp initiative I started at Worldline (previously Ingenico).
This second part will focus on a couple of practical experiments.
Because of the ongoing pandemic, the bootcamp had to be hosted fully remotely. After many attempts to try to have a clean workstation as a virtual machine everyone could connect to via AnyDesk (inspired by several awesome workshops of Llewellyn Falco & Jay Bazuzi) I had to give up and do something simpler. Both the virtual workstation that could access the company development environment and the AnyDesk remote control connection turned out to be impossible for me to get in this enterprise environment. That was unfortunate because it was my favorite setup as everybody gets the same experience, it can be as responsive as a local computer (at least with a workstation in the cloud) and most importantly, switching typist is seamless as all participants control the computer all the time.
As an alternative, we used Microsoft Teams to share and control screens. The typists would all, in turn, control the same computer (mine) remotely. This way I would get the advantage of a controlled environment, with all the tools and plug-ins that I wanted them to use (mainly ReSharper and Ncrunch) and know that it just worked.
The drawback was a laggy experience for the participants, who didn't like it but still bore with it for quite a while. Switching typist was quite easy and could even be done without any action from me, the host (previous typist would accept the control request from the next typist).
After around 6 months like that, the bugs encountered in Teams and the laggy experience made us want to try something else. We tried git handovers: each typist would work on their computer, with their setup, their tools and no lag. They would then pass the current work in progress to the next typist via a temporary git branch. We could have just committed whatever work was in progress on our main branch, but it would have meant sometimes committing code that would not build or that would break the tests and we wanted to avoid that. Luckily, we were not the only ones to have this issue and some tools exist to help us with this process. We tried mob.sh and we were very happy with it as it only requires to type one command to start as a typist, then another one when you're handing over to the next one. Then, the new typist had to start sharing their screen. All in all I would say the switch was as cumbersome as the solution using Teams we had before, maybe a even bit more. Using each our own tools is as much an advantage (no need to look for things) as a disadvantage (took me some sessions to convince everybody to install all the tools, and they still didn't have the same shortcuts and all, which didn't help when trying to encourage the participants to use them).
To conclude, I think for a short session/workshop (or for the first one) starting with one host and sharing control is the easiest to get started with people you don't know. For recurring sessions it might be worth investing in a little bit of alignment and learning to use tools like mob.sh to provide more development confort to the participants.
An issue we quickly had with git handovers is that at the start of the session, the computers of the participants always had something not ready, not open or even not working. This made the switch very painful: during the first 30-60min of the session every typist would start by saying "oh wait I'll open the tool" or "ah… I can't connect to the remote git repository" etc. The solution we found was very simple: start the session with our "mob start checklist" (don't you just love checklists? :-) ) which contained all the tools you had to open, all the commands you had to type in order to check the availability of all the things you might need during the session as a typist. Of course, the list kept growing as we encountered more of these issues. In my eyes, it turned out to be an excellent solution.
The session was initially planned like this : 30 min of greeting and reviewing what we learned. Then one hour of coding, a 5 minutes break and 40 minutes of coding. We would finish with a 15 minutes retrospective. This would fill the morning from 9:30 to 12:00.
After six months like that, some participants were frustrated by not being able to achieve more in one session and asked that we extend it by 30 minutes, making the second coding session longer. However, this was not the end of the discussions and it remained difficult to fit everybody's busy calendars while still achieving what we wanted.
We would close each session with a quick 15 minutes retrospective after which we would have a couple of actions or ideas to try for the next time. We would then always start the next session by checking that list out and either deciding to try that new thing, or check if the action had been done in some rare cases (but I tried to avoid this kind of "homework" as it's always difficult for participants to find the time and you'd better not count on it :-) ).
I explicitly set our pipeline to deploy each commit to our "production" environment (aka continuous deployment).
I also asked that the mob doesn't use any other branch than master.
This application of trunk based development coupled with the constraint that all committed code goes to production enforces what I consider a real continuous delivery mindset: you know that you can never break existing features and for this reason your changes are never blocking anybody from deploying if needed (in this case it was even systematically deployed as I said).
I wanted to promote the use of references like code smells, clean code or solid principles to justify choosing one design over another. This way we would avoid arguments like "I don't like this, I like that better" and instead say "Could we introduce a class to replace this string and avoid the primitive obsession?". It helps the discussion by skipping lenghty explanations and makes it less personal (it works only if all the team members share the same knowledge about the code smells, but that will be the case after this bootcamp :-) ).
In order to achieve this, I prepared what I called the "code smell panini" (a reference to the stickers we used to collect as kids). The idea was in essence to fill a big board with drawings of the code smells and other principles used in code review. Each "sticker" would be earned when we had a discussion about it because of the code we saw. Since the whole point was to help participants remember it, introducing the concepts slowly as we encountered real cases seemed like a good approach. The stickers had drawings that would represent the principles in a way that would also help memorizing them. Placing them on a board also helps remembering: "Feature envy? Ah, yes, it's the little one at the top!"
What started as a great idea I was quite happy with, ended up a bit disappointing. In a bit less than a year, we managed to introduce only a couple of very basic code smells. I suppose this could be an indication of another problem (a "smell"? :-) ). Maybe this bootcamp format never allowed us to dig deeper in code concepts, or maybe I missed opportunities by focussing on other things… I'll certainly try again, or maybe focus some new training activities only on this topic!
I believe by running this bootcamp for almost a year, I learned as much as the participants thanks to their openness and their motivation to try and experiment many things. I enjoyed the time we spent together and they seemed to have learned quite a few useful things. All-in-all a very positive experience!