Solution Seeker

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. Solution Seeker is one of them.

Introduction

Start programming only when you have at least three solutions.

I heard about this concept when I started being a programmer. It made some sense then, and now it has even more sense. Especially for problems when we care about: scalability, performance, speed, security, etc.

Purposes:

You need to find a very good solution for a problem. But the “good” part here needs to be very well defined in advance. What do you seek for: security, speed, scalability, etc.

The domain of the problem might be known or not to you. If it is known, you just want to expand you knowledge and find lateral solutions.

Concept

The two pairs sit down at the table and are not allowed to write any code until:

they think about at least three possible ways of solving the problem

they note on paper or in a text file the solutions

every solution has a clear definition of how the goals (security, speed, etc.) are going to be measured in order to make sure the solution is right

the solutions are prioritized: the simplest and with best estimated results will be the first one

they start prototyping the first solution and measure its performance

only if the first solution does not fit the criteria, the second solution is prototyped

go on until one good solution is found.

This idea is extremely useful for finding solutions on hard problems or in areas like startups and research&development.

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

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.

Yes, and…

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 the team members that always disagree try to build up on top of the ideas already presented.

Some members of your team are very stubborn and you want to show them that there could be other solutions than their own.

You want to improve solutions immediately when you see a smaller or larger improvement option.

You want beginners to feel they add value when pairing with more experienced people.

Concept

When working in pairs none of the pairs is allowed to delete the code of the other person. We are looking for a common solution, that both of the pairs will agree.

Why? Often I see that the more experienced programmers drive and give their solution as the best one (and sometimes as the only one). But even if you are not experienced, either with the specific language or framework or generally, you might have some good ideas for making the current solution better. In order to work on that attitude you can do ping-pong pairing with the rules Yes, and…

So the rules are:

none of the pairs can delete the code of the other.

at each step when switching from driver to navigator one needs to improve the existing solution and tests.

whenever one of the pairs tries to delete the code, the other needs to say “You should improve the existing one. Please go back and say Yes, and… I will do…“.

none of the pairs are not allowed to be angry on this request of not deleting code.

only unused code can be deleted, like for example after refactoring the code is not used any more. Both of the pairs must agree that the code can be deleted.

Sessions on this topic should be short, around 30-60 minutes. The first sessions should be supervised by a coach who will make sure the rules are understood and well respected. These sessions might become tiring, so make sure you choose a period of the day when you do not have other hard things to tackle.

Beginner’s Mind

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:

You have very stubborn programmers in your team and you want to make his views softer.

To any problem, your team says there is only one solution, and that is their solution. You want to let them see there are always alternate solutions, which sometimes are better.

You had issues in the past with architectural or design decisions, just because the problem was not understood sufficiently.

Concept

A very experienced and neutral person, ideally an external technical coach, will pair with the team members one by one.
The rules are that:

the team member will be the driver

the technical coach will be the navigator

the technical coach is allowed to always ask beginner, even basic and stupid questions like “what are you doing”, “why are you doing this”, “tell me what is happening in this code”

the driver is not allowed to be angry by the beginner questions of the technical coach; the driver needs to always explain what is their current idea, how they can implement it and why they chose this path.

These sessions should have a specific, very clear topic. The technical coach needs to make sure that each member of the team understood the purpose.
The pair-programming session should not last more than 30-60 minutes as it is very tiring for both of the performers.

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.

About

Pair programming is a technique in which two programmers work together to solve a task. They work on one computer, ideally each having their own keyboard in front of them.
There are two roles: driver and navigator.

The driver writes the code and takes the short time decisions. The driver should trust the navigator totally for the long term decisions.

The navigator reads the code of the driver and gives meaningful suggestions on how the code could be better. Also the navigator focuses on the long term decisions and thinks the strategic direction the code moves to.

Both the driver and the navigator need to verbalize their actions and concerns and to speak on the code.

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.

Brutal Refactoring Game

I wrote a post on the history of Brutal Refactoring Game, you can read it here.

In this blog post I want to tell you more about the workshop and about my experiences while facilitating it. Also I will add some tips for facilitators that want to try themselves this workshop.

The purpose of this workshop is learn what refactoring is, why it is so important to do refactoring often and immediately after you spot some coding smells. Often I ask programmers “when are you doing refactoring?”. The question has a vast number of answers from “when I think I need to”, to “once a month” to something like “every couple of tests”. But seldom I hear that programmers do refactoring all the time, in the minute the tests had passed from red to green”. This is where the format comes into place.

Taking Baby Steps

I wrote a post on the history of Taking Baby Steps, you can read it here.

Now I would like to tell you more about the workshop and the technique itself. While coding, for me it is very important to be focused on one idea. Why? Because this is how programmer mistakes appear in the code; some people tell them bugs. The other thing I am interested in is to have an undo button for every change. This is why I want to commit every 1-2 minutes.

The rules are the following:

Steps

Setup source control repository.

Setup a timer for 2 minutes interval when you start.

Write exactly one test

If the timer rings and the test is red then revert and start over.

If the test is green before timer rings then commit.

Restart timer (no discussions in between timers)

Refactor

If the timer rings and the refactoring is not complete then revert and start over.