In the past edition of Socrates UK, I met Gianfranco Alongi who told us about his team's experience with Mob Programming. It was the first time I heard about it. As the site says, Mob programming is people working at the same time, in the same space, at the same computer, on the same thing. Gianfranco said it was very useful for them.
At the beginning of November three of my fellow craftsmen and I joined a team of other 12 developers to work on a new project. We are building a DMS (Dealer management system) and an IMS (Importer management system). The project is very exciting but we don't have a clue on the domain. We are also a lot of people with different programming styles. So we decided to give Mob Programming a try and after a few weeks the results are very positive.
Some lessons we have learned along the way:
- Like with pair programming, navigators should take notes whilst the driver is at the keyboard, rather than disturbing him constantly.
- Only when the driver raises his hands off the keyboard we are allowed to discuss.
- Rotate frequently: it's faster to jump in the keyboard and do it yourself than trying to explain the code you envision.
- Limit the group size to 5 or 6 people. We find that 4 is a good number, more than that is not being productive for us. Sometimes it's useful though, when we want to define conventions for the whole team.
- The group should be stable: if new people join the discussion in the middle then we have to explain again and again the code and the decisions we have already made. It's like the never ending story.
- At some point I had to leave a session right in the middle of something. When I came back a colleague told me that the people who were shy or less proactive during my driving period, started proposing interesting ideas during my absence. The people considered "seasoned" or "experienced" should go away from time to time for the others to feel empowered.
So far the project is just fantastic. People are awesome, learning incredibly fast, very enthusiastic. Everyone wants to learn and contribute. We are all learning a lot and doing our best. I can't think of a better project. We are very lucky.
This is the first of a series of posts on how our team is practicing BDD. These are mostly notes to myself and our team so other readers may not find enough context to understand the points.
After a few weeks we have decided that:
- Although source code is written in English, the specifications are written in Spanish. Because the business is always discussed in Spanish, it's the language used to determine what we need to do. So the Cucumber scenarios are written in Spanish.
- There is a glossary of business terms to help us document the ubiquitous language. The glossary contains the translations from Spanish to English so that the source code expresses the same concepts.
- If developers need to change or adjust the scenarios for some reason (for instance, automation purposes), then business analyst have to validate the changes.
- Scenarios will be stored in only place only, and that place is SpecFlow (Cucumber). This means that business analyst need to have all the tools installed and access to the source control repository (Visual Studio and TortoiseHG).
- After the specifications workshop, scenarios are written in pairs or groups of 3 or 4 people. Two people is usually enough. We've realized that writing the scenarios in pairs help us come up with more questions and more ideas to simplify the problem.
- The automation of the scenarios should also be done in pairs, because this is yet another opportunity for us to detect inconsistencies or doubts. Well, in general we just pair most of the time.
- A user story is not ready for implementation until it's got at least 4 scenarios. We started with just one and the lack of context caused us to introduce wrong models in the code. Actually when test-driving a small function, we never start out with a single example but with a to-do list. Then we focus on each test writing the minimum code required but we do know where we want to go. This is the same but at a higher level.
- Given that our business analyst know how to read code, they should read the source code at the end of the iteration. By reading the part of the code inside the hexagon (we use hexagonal architecture), they can ensure the designed model makes sense.
- Scenarios should not repeat irrelevant details. If one scenario uses real data like a "plate number", then the following scenarios don't need to repeat the whole plate number but just something like "x". We should keep in mind that scenarios complement each other in terms of documentation. They should be indepdendent for execution but not for documentation.
- Triangulation: we can make a scenario go green quickly. However, triangulating the code that really works for all the cases falling under that scenario, may require more code. If the triangulation does not concern business details, we use NUnit to test-drive rather than SpecFlow. Scenarios are used for documentation, not for triangulation, unless the triangulation covers relevant business tips.
It was by chance that one of our business analysts came up to a mob programming session and got to see code related to the scenarios that we had defined together. Quickly he realised that we were introducing aliens in the domain (wrong models). It was because we were lacking some other scenarios. The fact that the code was in the wall with a massive font size and it really communicated our intent, together with the fact that the reader is very clever, made us discover an useful technique to double-check our assumptions.