#RemotePairProgramming Ep 004: Adi & Michel Daviot – Michel as Navigator (part 2)

The book Facilitating Technical Events is for technical trainers, coaches, events organizers who want to have a good event flow and happy attendees.
Support independent publishing: Buy this e-book on Lulu.

About

During this episode from the #RemotePairProgramming series we continue the exercise from previous episode. My coding pairing partner this episode is Michel Daviot.

Pairing Techniques

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.

The Problem

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.

Video

What we learned

Michel’s List

  • 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’s List

  • 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.

Acknowledgements

Many thanks to Michel Daviot for taking the time to record this codecast with me.

What’s Next?

Read more about Strong Style Pairing: http://llewellynfalco.blogspot.ro/2014/06/llewellyns-strong-style-pairing.html

Check the previous episodes of #RemotePairProgramming:

 

Subscribe

If you want to receive an email when I write a new article, subscribe here:

Subscribe for new articles

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe for new articles