Xavier Balloy

Back from SoCraTes France 2019

2019-11-15T00:00:00+00:00

From October 17 to 20, one of the key events in the software craftsmanship movement took place in France. SoCraTes-FR describes itself as an unconference — it's more of a retreat than a traditional conference. 

The agenda isn't known in advance. Instead, it takes shape each morning from the many workshop proposals that everyone is encouraged to submit. The October 18 agenda — so hard to choose with this many options!

Software quality is part of AXA's DNA, so it was natural for us to sponsor the event and send our developers. I was lucky enough to attend and discuss a wide range of topics — from DDD to code reviews, green IT, and many katas.

Here are some highlights from the discussions I had over those four days.

Code Reviews</h2>
I didn't expect code reviews to spark such intense discussions. To me, it's something everyone does as part of best practices when striving to improve software quality.
But no! Even code reviews have their detractors.
Their main argument is that reviews are usually done poorly. For example, reviewers don't pull the code locally — they just skim through it during a pull request or when someone presents code to them. In the end, reviews only catch naming issues, typos, formatting problems, or obvious bugs.
Meanwhile, reviewers rarely question the business logic being implemented, partly because the whole team doesn't know every feature in detail. Worse, the level of scrutiny varies based on trust in the author! We tend to trust someone who's been on the team longer and makes fewer mistakes.
Given this reality, some companies have stopped doing code reviews altogether, opting instead for much more pair programming and mob programming.
Pair Programming</h3>
Pair programming is a working method where two developers work together at the same workstation.
This technique proves useful for newcomers (whether experienced or junior) to learn the team's working methods and established best practices. It also avoids the potential back-and-forth of early pull requests.
Those back-and-forths are counterproductive: the same code gets reviewed multiple times, development stalls, and the developer may feel frustrated or take comments personally. Once this pair programming phase ends — which can be seen as mentoring and typically lasts several weeks — you can trust these people and stop reviewing their code entirely (or at least not every line).
Mob Programming</h3>
Mob programming is similar to pair programming, except the entire team works on the same feature! One key advantage is that the whole team shares both business knowledge and code ownership. You'll never hear "That's not my code/bug, it's Paul's" or "Who worked on this feature?" anymore. Since the code is written collaboratively, it's higher quality and doesn't need review afterward.
Doing mob programming is like pair programming to the power of n — meaning you get sustainable code. — Someone during a discussion at SoCraTes
Katas</h2>
During this event, I practiced several katas that helped me discover a new language (Haskell) and new ways of coding. A code kata is a development exercise that helps you hone your skills through practice and repetition.
If you're interested, here are the katas I practiced:

FizzBuzz</a></li>
RPN Calculator</a></li>
Roman Numerals</a></li> </ul>
TCR Instead of TDD</h3>
I had the chance to try TCR, an acronym for test && commit || revert. It's a programming method proposed by Kent Beck</a> (the inventor of TDD). The principle: when you run tests, if they fail, you revert your code!
We applied a slightly less extreme version during the kata. Before running tests, we'd bet on whether they'd pass or not. If we won the bet, we'd commit; otherwise, we'd revert. This approach still lets you go through the "red bar" phase where you see failing tests.
I preferred this approach. You spend less time "running tests in your head" to avoid seeing all your code (including the latest test) disappear. Most importantly, you keep the benefit of seeing your tests fail before they pass — which I consider a crucial part of the TDD I practice daily.
However, TCR does force you to go through the obvious implementation phase of the test (bet it'll be green, commit) before refactoring (if it doesn't work, revert and return to a working state).
Fish Bowl Mob Programming</h3>
Before SoCraTes, I'd heard of mob programming but had never tried it. During one kata, we experimented with a specific facilitation technique for mob programming: the fish bowl.
The rules are fairly simple:

A driver has the keyboard. They only code and don't make decisions.</li>
A navigator tells the driver what to do. They're the only one speaking.</li>
One chair is open for questions. But beware — only questions to better understand the code (e.g., an unfamiliar syntax) or the business logic. You can't ask questions like "Why are we doing it this way?" — in that case, you take the navigator's seat!</li>
Everyone else stays silent and can take the driver's or navigator's place at any moment.</li> </ul>
I really liked this technique for mob programming because it prevents the chaos that can arise when everyone tries to code at once. In those situations, the driver doesn't know what to do, and it's hard to make progress.
Since the event, I've tested this technique during a kata and the format was well received. However, like other techniques, I think you need to practice it first before using it daily on production code.

My Global Day of Code Retreat 2017

2017-11-19T00:00:00+00:00

My takeaway from the Global Day of Code Retreat 2017. 
Last Saturday, I attended the Global Day of Code Retreat</a> hosted at AXA WebCenter (Lille, France). A code retreat is an event where you can perfect the way you write code, design your application, learn new ways of coding... Unlike in your everyday job, the final goal is not to finish the exercise but to improve your skills! During this event Christophe Thibaut</a> was our facilitator. It was his first time as a facilitator but he was so good no one realized it!
We did six iterations of Conway's Game of Life</a> kata (45 minutes of coding and 15 minutes of debriefing). During every iteration, we had different constraints. After an iteration, you have to destroy your code. I did every iteration in Java using IntelliJ (my everyday language and IDE) in ping-pong programming (using TDD of course) with a different person.
Conway's Game of Life</h2>
The rules of Conway's Game of Life are simple. In an infinite orthogonal 2-dimensional world, the following rules apply:

When an alive cell has fewer than 2 neighbors it dies.</li>
When an alive cell has 2 or 3 neighbors it stays alive.</li>
When an alive cell has more than 3 neighbors it dies.</li>
When a dead cell has 3 neighbors it becomes alive.</li> </ul>
1st iteration</h3>
Constraint: none. This iteration is mostly to discover the problem and the rules.
We both already knew this kata but always had the same approach so we decided to do it another way: we started by implementing the rules. We went quite far: we had all the elements and were assembling them. The design of the grid emerged by itself so we didn't have to think about which structure to use. It's the best approach I used so far and used it during the other iterations.
2nd iteration</h3>
Constraint: no primitive in the public API of our methods.
We had the same approach as in the previous iteration. The hardest thing was to define the coordinates of the cells without using int</code>. We cheated and used Integer</code>, that's Java after all.
During the debriefing, we shared our difficulties and someone suggested defining the neighbors relative to each other. Using top, right, bottom, and left. I think it's a great idea because you can chain them and it is infinite (by using an int</code> I have a limit, a huge one, but still a limit).
3rd iteration</h3> Constraint: no conditionals. One of the most difficult constraints for me… How to remove the if in the method that checks if a cell is dead or alive?! Finally, we used Map<Integer, Function></code> to get the rule corresponding to the number of neighbors. I don't usually use this pattern but it improves the readability of the code and every Function has only one role (the S in SOLID)! However, it was quite hard to come to this idea and we should have written the code with conditionals then refactored it. I have no idea why we didn't use the refactoring phase of TDD to do it. 4th iteration</h3> Constraint: not only object-oriented development (Functions & Types over classes. Purity over mutability. Composition over inheritance. Higher-order functions over method dispatch. Options over nulls). This was the hardest constraint. I'm not used to functional programming so I needed to change the way I think, which is hard in 45 minutes… Even writing the first test wasn't easy. Finally, we wrote specific functions for every functionality (one for each rule, one to count the number of neighbors…) then composed them. 5th iteration</h3> Constraint: mute programming. I thought it would be an easy one because we both knew the problem and already solved it a few times. However, it wasn't so easy because it's hard to tell the intention of a method or a variable. We had to rename them a couple of times to know what it meant for both of us. This time writing the rules first wasn't the best idea because once written it was hard to continue and to explain (without speaking or writing) what we wanted to do! Communication is really important in a team! 6th iteration</h3> Constraints: TDD as if you meant it & mob programming. The most fun! We were disciplined enough to listen to each other so it didn't end up in a big mess. But it was hard for some people to talk and give their point of view. When the group is working well sometimes you don't want to slow it down. However, it could be interesting to have a higher vision of what we are doing and it could be the opportunity for refactoring some code. In this last iteration, we wrote the simplest code in the test to make it pass. At first, it looked absurd because it was very far from the code we all produced during the day. But it's a good way to experiment with things and finally design our application in a new way. What did I learn?</h2> This day was very interesting and I'm glad I spent my Saturday there. I met passionate people, I had fun and I learned new things that I'll try to apply in my everyday job. Communicating through the code is hard and sometimes a meaningful name for me might not make sense to someone else. Next time I do a code review I will challenge even more the name of the methods/variables.</li> I will try to write more functional code: it's harder to write when you're not used to but it's really simple to test.</li> I will write more code in my test to experiment: you don't have to switch to a different class to see what you are doing and you can easily refactor everything once it's working.</li> Next time I will write an if</code> (probably tomorrow) I'll ask myself if I can do without it.</li> </ul>