Simple^4 Xiaoming Wang

Last year, our team ran into a few product quality and team training problems. At that time both code review and pair programing were brought on the table in order to resolve these problems.

Background:

The team had been using Ruby on Rails to build a vertical search engine and a legal related business Web application.

Problems:

1. Many function can not be reused or migrated or refactored.
2. We didn’t know that somebody had wrote a public or share library(gems)
3. Code readability problem:  variable names, function names or class names(code style) are hard to understand
4. Different understanding of business domain knowledge
5. Different skills set of testing a product.
6. Team is lack of Rails experience.

Root cause/concern:

By asking five whys to ourselves, we figured out the root cause of the problems above are that the team is lack of engineering experience, practices; previous working environment did not train people to work under a good discipline , previous company culture, release schedule was too tight, and project was not well scoped.

After we figured out these root cause which you might not be able to tell from the phenomenon, we decided to take actions on below solutions.

Solution:

• Pair programming can resolve 1,3,4,5,6, Pair programming can also help us team building. Pair programming can reduce tasking switching, and drive team to focus more on producing high quality code.
• “Check in” code review can resolve 1, 2, 3, code review is difficult to manage, also has negative impact on team productivity and spirit.
• Integrate tools like “Checkstyle” into CI env to resolve 3.
• Bring back test coverage tool into CI

In order to successfully adopt Pair programming practice in our team, I designed a guideline. See below:

Process

0. Eng decide who pair with whom
1. Eng pair pick up story after stand up.
2. Eng decide one of the pair as story owner who should not move to next story until it is done.
3. Eng switch pair everyday or every story.
4. As soon as story is picked up, a pair run story kick off, break stories into tasks. They put tasks either in a sticker or trac.

Definition

Pair programming is an agile software development technique in which two programmers work together at one work station. One types in code while the other reviews each line of code as it is typed in. The person typing is called the driver. The person reviewing the code is called the observer (or navigator). The two programmers switch roles frequently.

While reviewing, the observer also considers the strategic direction of the work, coming up with ideas for improvements and likely future problems to address. This frees the driver to focus all of his or her attention on the “tactical” aspects of completing the current task, using the observer as a safety net and guide.

See Wikipeida:

Purpose

• Understand the whole system over know one component well.
• Share knowledge over being bottle neck.
• Collaborative ownership over I am the hero.
• Quality of the product over quantity of the code.
• Noise over silence.

Environment Set up

Pair station: 2 monitors, 2 keyboards, one driver, one navigator, same IDE

Howto

• How to pair programming in general:

Start from Stand Up meeting. After standup meeting, engineer need pick up one story/task and decide who will pair with who. For each story, there will be one owner who will hold the story to its finished point. The owner take 100% ownership of the story quality.

Pair starts from understanding the story. A pair should go through the story together first and ask questions to each other as well as product owner. After the pair both understand the requirement 100%, you should start a small design session (how the pair wants to design the story). After the pair reach the agreement, the pair start implementing the story. When the driver is typing the code, the navigator need either follow the code or think of the test cases to test the code. Vice Verse. The pair discuss the implementation, design, tests all the time. If there are no noise, no argument, you are not pairing.

Each checkin need have both pair’s name in the comments. E.g. Check in comments: Complete register validation and tests — Tom & Jerry

• How to drive:

The driver need work on a task from the end to end. After the task is done, he need pass the driver seat to the navigator, then he becomes the navigator. A driver should not pass the seat to navigator unless you have both the functional code and test done of your piece.

• How to navigate:

Never stop giving direction, thinking of test cases, design. Ask the driver seat back when you think that a small unit of work is done. Small unit of work means part of the story, including “test-function”.

Q&A

• If I work alone, how could I pair?
  • Either ask someone to review your code before you merge into master every time you merge the code or ask someone to review it by the end of each day.

• If I work at home late night, how could I pair?
  • Grab your pair in the next morning, ask him to review your code.

• What task should I pair to do, what should not?
  • It would be eng’s judgment call but this is the suggestions from widely used industry practices:
    .
  • Need pair: any functional story, major technical task.
  • Do not need pair: bug fixing, spike, env set up and config.

• If I do not like pair programming, or it shows me down what should I do?
  • It does happen sometimes. My suggestions are: 1. try it and see what you and your co-worker can benefit from. There are thousands of software develop teams are using it right now on this planet. 2. If you still do not think that it shows you down dramatically, go back to the code review approach. Whenever, you need check in code into master, you need have someone to review your code.

• We use different IDE, how could we pair?
  • Try to pick one that you guys both like, if it is possible. If it is not, can one of you try to learn the other and switch to it. If it still does not work, try Vincent’s way.

Reading List

Extreme Programming
Interesting blog post
What Kent said
What Naresh said

Last week, I had an opportunity to present “an A start up agile adoption story” in the mentoring session of Innovation Works, a Chinese investment company who focuses on helping young entrepreneur to found their business. It was a pleasant experience when you saw so many talented kids showed their interest in starting up an mobile internet or e-business, or online games companies. I was impressed by the passion that each teams wanted to improve themselves as well as the teams.

For details, please see the online presentation on (http://www.gensee.com/chuangxin/plus/view.php?aid=68)