Question (Michel): When would you use this remote pairing techniques and pairing (like Strong Style, Farsight Navigator, etc)?
Answer (Adi): When people are very used to their code, but don’t know how to refactor it, it is very useful to use Strong Style, because the Driver would know how to navigate around the code, but won’t know how to refactor or use a specific legacy code technique. The Driver knows the language, the project and so on, but the Navigator knows the techniques.
With new code Strong Style is very useful when you get stuck. And then the driver took control, pushes the rhythm and the steps to have progress.
Question (Michel): Do you explain to the people you use Strong Style?
Answer (Adi): Not really, because just coming up with theoretical concepts up-front feels weird. I just say “let’s pair and try this”. Maybe at the end of the session I might explain.
The other approach is a game called Farsight Navigator, where the Navigator looks far away for the design, and the Driver takes the small decisions. This technique works quite well, but you need to have very good Navigator skills to know where the design is going. So the role of the Navigator is to know which design options are not good and the solution would get stuck.
With Strong Style the Driver doesn’t need to know anything about the code, design, direction, etc.
Scientists have sticks of different length and ants that walk on the sticks. When there are more ants, they collide on the stick and both ants change the direction. We need to compute the time each ant spent until reaching the end of the stick. During the codecast we need to model this problem using TDD and Strong Style Pairing. Adi is the navigator and doesn’t know the problem, while Michel is the Domain Expert and the driver.
What we learned
- We go much smaller steps than what Michel is used to
- The first steps were in very small level of details of triangulation
- We worked and we didn’t spend our time discussing
- We were making progress
- Each 5 minutes we had a new feature. And this worked because the driver was trusting the navigator
- Michel was surprised by the Strong Style Pairing: the driver has less autonomy than the usual
- Taking Baby Steps in design is useful for not getting stuck. Usually for this problem Michel observed that there are too many discussions about up-front design
- The approach Adi used to introduce only one concept at a time for each step was really good, as the Michel as a Driver was not in a fog
- We made the switch driver-navigator at a good moment, when Adi as a Strong Style Navigator got a bit stuck, but Michel had a better idea how to continue
- As the Navigator you have to let go the style the Driver uses
- As a Navigator Michel tried to write the test cases on paper.
- Adi explained the Farsight Navigator is another option of pairing, with more autonomy for the driver
- Adi felt like being in a fog at the beginning, because not knowing the problem especially as a navigator in a Strong Style pairing
- It felt nice we could collaborate with the tests and the production code
- Felt very well that we had progress
- Trust is very important when we do pairing
- It is very important to switch well, at a moment when the other can guide faster towards a solution
- In the moment when Adi doesn’t know where to get, he takes smaller and smaller steps until having the confidence he can go on with a bit bigger steps.
- Typically I just let go when Navigating, and focus on the business because the rest can be refactored
- Adi wrote just at the beginning which tests to write, by using the Behavior Slicing technique.
Many thanks to Michel Daviot for taking the time to record this codecast with me.
Read more about Strong Style Pairing: http://llewellynfalco.blogspot.ro/2014/06/llewellyns-strong-style-pairing.html
Check the previous episodes of #RemotePairProgramming:
- Ep 001: Traditional Style Pairing
- Ep 002: Strong Style Pairing with Llewellyn Falco
- Ep 003: Strong Style Pairing with Michel Daviot