With Agile2016 conference, I had a chance on a yet another glimpse into how a group of programmers work together, and how that shows up in results. Llewellyn Falco wrote a blogpost on 5 ways to do decision trees in C#. I feel that nicely shows how you can have many different solutions, and how some of them have more limitations than others, but it doesn't show what I always find fascinating: how the deeper understanding of having the five options was born.
Each morning, there would be some group working on some coding kata. For the piece of code in question, the mob in the morning came up only with one solution. We often talk about mobs as things where bunch of great ideas emerge, but in this particular time-limited mob, they got to one solution.
What then created the others was that the limitations of the first solution left a nagging feel for one of the participants. And with a little sink-in time, solution 2 emerged. Another mob or pair came together to implement that, and then the magic started.
From two competing solutions, they quickly got to five competing solutions and a grounded discussion on which of the actual implementations they would consider the best.
The rule in mob that when you have two competing solutions, you do both just made even more sense. With two available, creativity of the group steps into play and produces more.
My lessons learned on watching this unfold:
Each morning, there would be some group working on some coding kata. For the piece of code in question, the mob in the morning came up only with one solution. We often talk about mobs as things where bunch of great ideas emerge, but in this particular time-limited mob, they got to one solution.
What then created the others was that the limitations of the first solution left a nagging feel for one of the participants. And with a little sink-in time, solution 2 emerged. Another mob or pair came together to implement that, and then the magic started.
From two competing solutions, they quickly got to five competing solutions and a grounded discussion on which of the actual implementations they would consider the best.
The rule in mob that when you have two competing solutions, you do both just made even more sense. With two available, creativity of the group steps into play and produces more.
My lessons learned on watching this unfold:
- Actively try to find several ways to solve a problem
- Individuals with a nagging feeling are a powerful driving force for improvement
The niceness of the solution (an aspect of technical quality) improved because of a persistent individual. But as that idea of different solution was again fed into a group, the group got a lot better solutions out than the individual.
With mobbing, we keep repeating the idea that it is not about the most you can do, but about the best you can do. We need to recognize more often how much of an impact the passing idea around through different minds actually has on what ends up in the code. And individual is a trigger, but the group is needed to take that trigger to its full potential. Solo work misses a lot of this. Except of course for the wonderful people who keep talking about the five voices in their own heads.
