Blog post series
This blog post is part of a series about pair-programming games. To read about more please click see more sessions on pair-programming games.
- Make experienced navigators become better
- Focus on long-term design decisions
- Create design incrementally
- Teach others how short-time design decisions can affect the design on the long term
Both the driver and the navigator need to know very clear which is the purpose, the destination, of their current code writing process. This concept works extremely well if you are doing Test Driven Development and you want to produce design incrementally.
The roles of the development are very well separated:
- the driver is not allowed to think too much ahead
- the navigator is not allowed to say anything about the implementation details unless some decisions would drive them out of their course.
- in the case of conflict they need to stop and decide together which is the best approach
- needs to focus only on the small implementation details.
- will write code in small batches of maximum 5 minutes and will make sure the code is functioning well
- needs to see how the code will develop on the long run
- if the driver tries to think too much ahead, the navigator needs to ask him questions until the driver understands why that decision is a bad one.
- needs to be a very experienced person in programming and in software design
- needs to keep their calm and explain always the objections to some path
If you want to have an easier far-sight navigator session think to do a session of behavior slicing, value sampling and then order the resulting behaviors from simple to complicated. This activity will give you a first list of tests you need to implement. This list is just a temporary list, as some tests might be split, some new ones might appear or some of them might need to be discarded.
In the case of a problem where we cannot really know how to proceed we can apply this technique in production. If done well, we will have the simplest design possible, custom created for the problem we want to solve. We will write the minimum amount of code, but further we will minimize our possible design mistakes by focusing more on the design than usually.
This technique prevents us from doing mistakes that are hard to repair afterwards. You might say that you are doing TDD with special focus on long-term design decisions.
Whenever I used this technique, the efficiency of reaching a solution was astonishing from both the time spent and the quality of the solution point of views.
This is the hardest pair-programming game I know. The purpose of this game is to make experienced navigators become better. I would recommend this only after at least 6 months to one year of continuous pairing from both of the pairs.
Have you read Dune by Frank Herbert? If you did not please read it because I guess you will like it. If you did read it, then you might remember the Spacing Guild and how they could guide the space ships by their special skills and protect them from danger. In the case of this game our navigator is like a Guild Navigator from Dune.
The navigator needs to have special skills of pairing, programming, is extremely experienced in software design and is a very good communicator.
When will become a navigator with a far-sight?
Image credit: http://dictionaryproject.files.wordpress.com/2010/08/compass.jpg