Tag Archives: Pair

Talk: Wildcard Conference 2013 – Sherlock Holmes and Pairing

Even Sherlock Holmes was pairing. Are you? Let’s find some good practices in the talk below about Sherlock Holmes and Pairing!

During my work I am used to pair with my colleagues on basically anything. I do pair-programming when I develop software, we use pairing when we deliver trainings or when we write articles. I often do remote pair-programming with strangers. The most things I learned during the last years were by working in pair with someone I barely knew.
Pairing for me has the following main advantages:
– I learn a lot from my pair
– I extend my comfort zone and I collaborate better with anyone
– the product we work together is a lot better because four eyes are better than two

Please find examples from the activities of the well-known fictional character Sherlock Holmes on how his pair Dr. Watson helps him become better and finding the answer to their riddles.

 

 
And here are the slides for the talk Sherlock Holmes and Pairing

Pair-programming game: Farsight Navigator

Farsight Navigator

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.

Purposes:

  • 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

Concept

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

The driver

  • 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

The navigator

  • 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
Farsight Navigator

Farsight Navigator

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

Outcomes

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.

Remarks

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

Pair-programming game: Silent Programming

Silent Programming

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.

Purposes:

  • Useful when you have talkative people in your team that do not agree or agree but do not write enough code for one task.
  • The code is not easy to read

Concept

The two programmers are not allowed to talk.
All the communication is made through code.
They are not allowed to use paper or write comments in the code or other files.

Silent Programming

Silent Programming

Read More →

Pair-programming game: ping-pong

Ping Pong Pair Programming

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.

Purposes

  • Learn pair-programming easier
  • Force the “know-it-all” programmer to see other ways of writing code
  • Force the “know-it-all” programmer to collaborate more
  • Push for collective code ownership

Concept

The roles driver and navigator change often inside the pair.
This activity is like a game of ping-pong of the roles between the two members of the pair. They both can take short time decisions while being a driver and can spot strategic design decisions while being a navigator.
Refactoring can be made by any of the programmers on their turn, but only when the code and the tests are stable.

ping-pong

Read More →