10 Pair Programming Best Practices Questions & Answers

A couple of weeks ago, I wrote a guest post on Philippe’s blog where I answered 10 commonly asked questions on the Pair Programming Best Practices. Below is a snippet of the blog, you can read the full article here.

Pair programming is not just sitting together in front of an IDE. Here are battle tested answers to common questions that will make pairing work for you.

Philippe and I are well known to be advocates for Extreme Programming and its practices (well Philippe more than me, but I will share some of the credits ūüėÄ). We were asked lately to participate in a Q&A session to share with our experience and recommendations on applying pair programming within a dev team.

Question I: When to do Pair Programming?

All teams do pair programming in one way or another, even if they don’t like to admit it!

Almost all developers have the tendency to ask a colleague for help when stuck on a complex piece of code or a bug, this is a form of pair programming! If we acknowledge that the four eyes principle can help solve complex problems faster, then why don’t we apply it all the time?

Going back to the question, … (continue reading)

A good commit message can make a difference!

Some developers have a habit of committing their code without a clear commit message.

I was one of them! Now, I consider that to be a bad habit.

With time I realized that it is hard to remember the intention of an old commit by just looking at the code. It becomes even impossible when reviewing a colleagues’ code.

In this post, I will be sharing a template message I adopted with one of my previous teams.

For simplicity, I will be referring to one of my commits to a fork of the GildedRose-Refactoring-Kata on my GitHub account.

Message Template

Below is the template. As you can see, it is split into four colors. In the next part of the blog, I will break down the message to explain each of its sections separately.

[Issue Tracker #] One-line summary of the commit description 

Why is this change necessary? 
  - Detailed description 1
  - Detailed description 2

Section I – ‘[Issue Tracker #]’:

Between the two brackets, I write the issue number corresponding to this commit. The format here varies depending on which issue tracking system I am using (ex: [ProjectName-123] for Jira and [#123] for Github.)

Message so far

[#5] One-line summary of the commit description   

Why is this change necessary? 
   - Detailed description 1 
   - Detailed description 2 

Section II – ‘One-line summary of the commit description’:

In the second section, I try to summarize the full commit in just one sentence. Failing to do so means that my commit is doing more than one task and needs to be broken down.

Message so far

[#5] Move the constants out of the GildedRose class

Why is this change necessary? 
   - Detailed description 1 
   - Detailed description 2 

Section III – ‘Why is this change necessary’: 

In this line, I try to answer the question ‘Why is this change necessary?’ In most cases, this line is a copy of the ‘Issue Title’.

Message so far

[#5] Move the constants out of the GildedRose class 

In order to, refactor and clean the code of GildedRose
   - Detailed description 1 
   - Detailed description 2 

Section IV – ‘Detailed Description’:

Finally, I replace the items of the list in this section with a detailed description of the important technical changes I did in the code. Here I try to think of what I should remember if I was to read this message a couple of months ahead.

The final commit message looks like

[#5] Move the constants out of the GildedRose class 

In order to, refactor and clean the code of GildedRose
   - Make MAX_QUALITY, MIN_QUALITY & MIN_SELL_IN_DATE as local variables ItemVisitor
   - Move AGED_BRIE string to the AgedBrie class
   - Move SULFURAS string to the Sulfuras class
   - Move CONCERT string to the Concert class
   - Adapt the tests accordingly

By just reading this last message, anyone should deduce that firstly, in this commit I only moved some constants from the GildedRose class. And secondly, the commit was part of a larger code refactoring of the GildedRose class.

How is this helpful?

So, why do I consider this to be helpful?

Here are my reasons:

  1. Forces me to code in baby steps and thus have small commits.
  2. By having small commits, it would be easier, later on, to track down bugs.
  3. Makes code review easier and faster
  4. Most SCMs and tracking tools are now integrated, that makes linking commits to an issue seamless. This link has 2 benefits:
    1. By just adding the ‘Issue Number‘ in the message, I can refer to the issue’s details to view all the corresponding commits.
    2. Limits my development to only the features and bugs in the project’s backlog. I won’t be submitting any useless code.
  5. Serves as a documentation for my code. More than once, I referred to those messages when writing a detailed technical report of our product.


At first, it was a bit annoying to write this message for each commit. But as we realized its benefits, it became a habit for us!

You don’t have to adopt this exact message, you can come up with any format you think is good for you as long as it is clear and concise.

Enjoy coding ūüôā

My takeaways from a TDD debate between Cope & Uncle Bob

As a developer, there is a high chance that you had a debate on the value of TDD in building software, especially if you apply it!

I had a lot of those debates!

A couple of months ago, I came across such a debate between Jim Coplien and Robert Martin (Uncle Bob). I found this discussion kind of interesting especially that it involves two leaders in software engineering.

You can watch the debate here:


Here are my takeaways from the discussion:

Three Rules of TDD

Uncle Bob defines the following three rules for applying TDD:

  1. Don’t write a line of production code without having a corresponding failing test
  2. Don’t write too many failing tests without writing production code
  3. Don’t write more production code than is sufficient to pass the currently failing test

Architecture is Important

Jim points out that he has no problem with those rules, his concerns are more architecture related. Jim and Uncle Bob would argue for more than ten minutes to finally reach an agreement on the importance of architecture. The below five points summarizes what they agreed on:

  1. Architecture is very important
  2. It is entirely wrong to assume that the code will assemble itself magically just by writing a lot of tests and doing quick iterations
  3. Design evolves with time and should be assembled one bit at a time
  4. An Object should have properties to give it meaning. At the beginning, those properties should be minimal.
  5. Architecture shouldn’t be created based on speculation

TDD and Professionalism

Probably the only disagreement you can sense from this¬†debate is what defines¬†a professional¬†software engineer.¬†For Uncle Bob, it is irresponsible for a software engineer to deliver a single line of code without writing a unit test for it.¬†Jim, on the other hand, considers ‘Design by Contract’ to be¬†more powerful than TDD.

My Point of View!

Personally, I have been applying TDD since I joined my team three years ago. After experiencing the benefits of this practice, we got to a point where we don’t write or refactor any line of code without having a¬†corresponding unit test!

In addition to that, I had the chance to coach other developers by running coding dojo sessions at work.

All that makes me say that I agree more with Uncle Bob on the topic of professionalism!

  1. Coplien and Martin Debate TDD, CDD and Professionalism

An agile approach to defining your product vision!

‘What¬†is your team¬†working on?’

Of course, you’ve heard this question many times before and probably your answer will slightly differ from your teammates’. But, with the help of two agile team-building activities, you can eliminate such a difference and reach an alignment with your teammates on a description for your team and product. Those activities are ‘Collaborative Product Vision‘ and ‘Defining the Team Vision Statement.’

In this post, I will only be covering the product vision activity.

How to run the activity?

Here is the template of the product vision:

FOR (1. target customer)
WHO (2. statement of the need or opportunity)
THE (3. product name) IS A (4. product category)
THAT (5. key benefit, compelling reason to buy)
UNLIKE (6. primary competitive alternative)
OUR PRODUCT (7. statement of primary differentiation)

Here are the steps to simulate the activity:

  1. Write the statement on a board for all to see.
  2. Split your team into groups of two or three
  3. Give the groups 5-10 minutes to fill in the seven blanks
  4. Ask each group to present and explain (if needed) the vision they came up with
  5. For each blank, ask the team members to individually vote for their favorite replacement
  6. Replace each blank with the phrase of highest votes
  7. Read the new statement out loud
  8. With the team apply some changes if needed

The Benefits

I am writing this blog because I think this is a nice activity for any team! So far, I have played it with three different teams, existing and newly established ones.

Here are some benefits of playing this activity:

  1. Good activity for team bonding especially new ones
  2. Aligns all team members on one vision of the product they are building
  3. Aligns all team members on what is considered as in and out of scope of the product
  4. Helps teams in identifying their main competitors
  5. Highlights the major difference between the product and its competitors
  6. A short but meaningful description of the product for upper management, visitors, and newcomers


FOR Outlook Users 
WHO want to keep track of time spent in meetings
THE MeetingReporter IS An outlook-addin
THAT generates time reports from the calendar 
UNLIKE existing tools where you have to manually insert time spent
OUR PRODUCT will parse the calendar and automatically generate different reports based on meeting category

Above is an example!

It is the vision of the tool I am writing on my free time! From this short statement and without any further explanation, anyone should understand purpose and major feature of this tool!


Some people consider such activities as a waste of time. Obviously, I disagree! This is an occasional activity that takes between 15 to 20 minutes depending on the team’s size. Thus, it is an excellent candidate for the first activity of the team’s retrospective!

I encourage teams to try it. For those who do, I am pretty sure you will be posting the outcome on your team’s home page, just as we did!

  1. Fun Retrospectives
  2. Collaborative Product Vision
  3. Defining the Team Vision Statement

XP Days Benelux

On the 24th and the 25th of November, I was (with ten of my colleagues) in Heeze, Kapellerput in the Netherlands¬†attending the two days conference ‘XP Days – Benelux‘!

The sessions at the conference were categorized as “Technology and Technique,” “Customer and Planning,” “Team and Individual” and “Process and Improvement.” And some of which were game based sessions!

In this blog, I will be sharing my feedback on two games I participated in!

LeanStartup board game

Led by: Sven Dill and Frederik Vannieuwenhuyse

The purpose of this game is to introduce participants to the practices and principles of Lean-Startup by simulating a business where each group has to produce a product and sell it to customers.


Game Rules

In the beginning, the game seemed a bit complex or vague, but things started to get clearer after the second iteration. Here are some of the game rules:

  • Split the participants into four teams (ideally three per team)
  • Each team¬†is a functional company responsible for building a product
  • The board represents the market, where each is a customer requesting some features
  • At each turn, the team can distribute their resources¬†on building features, investing in their company, experimenting or selling a feature
  • Through experimenting, the team can flip a tile to learn the requirements to sell the feature.
  • At each experiment, all the participants get the chance to learn new vocabulary from the lean-startup!
  • The team who reaches the red tile (in the middle of the board) first wins the game.

LeanStartup Vocabulary

During the session, we came across many lean-startup vocabularies, but here I will only be mentioning five of them!

  1. Pivot or Preserve: Certain challenges might force entrepreneurs to make a major change in their strategy. That change is called a Pivot!
  2. Idea Theft: Finding a compromise between the fear of idea theft (someone stealing your idea) and gaining knowledge is not an easy task. But, it is more important to gain knowledge than being afraid of spreading your idea!
  3. Concierge MVP: In some cases, you might need to create a fake processing MVP. That means what is happening in the background is not what it looks!
  4. Startup Machine: Put your idea to test by going to streets and asking people what they think about the product
  5. Startup Weekend: This is an activity where people of different backgrounds (dev, marketing, designers, etc.) meet to start building the first version

Take Aways

This game can be played by startups or even teams at large enterprises! And at the end, players should have got an idea of what Lean-Startup is. And more importantly, they will learn some of the factors that can play a role in any team’s failure or success such as competition, luck, technical excellence, failing and successful experiments, etc.

Agile Self-Assesment Game

Organized by: Ben Linders

As the name indicates, this game helps teams to assess how agile they are.

The game can be played by either an existing or a new team. In the case of an existing team, the results can be a base for a plan to change or improve their agile process. Whereas, for a new team this activity can be considered a futurespective activity as it defines the team’s first iteration.


The game consists of 52 cards, where each card holds a sentence on applying an agile practice. To play the game you should follow the below instructions:

  1. Place the cards on the table
  2. Each member picks a card and reads it out loud
  3. The team discusses the card then place it under one of the following categories:
    • Not or inconsistently done

    • Consistently done, but value can be increased
    • Consistently done, valuable practice for the team
  4. After all the cards are visited, pick the ones under the 1st and 2nd category
  5. Have a discussion how to improve, change or remove those practices from your process
  6. If the cards to be discussed are too many, you can use voting to pick the most important ones for the team



Below are statements taken from five cards:

  1. The team is empowered to make decisions
  2. The team is self-organized and doesn’t rely on management to set and meet its goals
  3. Software is tested and working at the end of each sprint/iteration
  4. All code changes are reversible, and it is possible to make a release at any time
  5. The team has a Definition of Done which defines their way of working and is used to check if a user story is ready

To know more about this game, you can check Ben’s¬†blog¬†on this session!

Until next time

I recommend those games to agile teams. Personally, I will be organizing two sessions with my team soon at Murex!

Finally, thanks to the organizers for setting up such an amazing and successful conference! See you next year! Probably as a speaker ūüėČ

Extreme Practices – Agile Tour Beirut

In my previous post, I shared with you how Philippe¬†and I prepared for our talk “Extreme Practices.” In this post, I will be briefing the talk’s content; starting with the pitch and ending with the feedback! Philippe has already posted a blog on the talk that you can read¬†here.



Each of the speakers had to brief their session in a thirty seconds pitch. This was mine:

This is unusual for me, because my co-presenter is in Paris! Philippe and I will demonstrate how we adopted the practices of Extreme Programming in our distributed team. We will also have two live demos; the first on remote pair programming and the second on remote meetings.

The talk

The audience started taking their seats; and in a couple of minutes, the room was full! We started by engaging the audience with three simple questions!

Who goes to work by car?

Who goes to work by bus?

Who goes to work on Skype?

Extreme programming

After introducing ourselves, our team and Murex, we spent the first half of the talk discussing four of the XP practices and their benefits.

  1. Ten Minutes Build
    • Helps developers stay¬†focused on what they are doing
    • Shorten the feedback loop
    • Encourages developers to submit frequently thus resulting in easier bug analysis
  2. TDD
    • Only coding what makes tests pass decreases the possibility of generating bugs
    • In most cases, a failing unit test is enough to detect where the bug is and thus reducing the need for debugging
    • The refactoring step drives to clean code
    • Finding difficulty¬†writing a test is an indication that¬†refactoring is required
  3. Pair Programming
    • Benefits:
      • Newcomers tend to learn faster and submit on their first day
      • The quality of our code has increased
      • We didn’t notice any negative any impact on productivity
      • It helped us build a bonded team
    • Difficulties
      • It is very tiring for both the driver and navigator
      • It is risky because some developers¬†prefer to work alone
  4. Retrospectives: For this part, we explained the five stages of our retrospectives
    • Check-in/energizer
    • Throwback
    • Collect insights & discuss
    • Actions
    • ROTI

Extreme programming in remote mode

Our second half of the talk was dedicated to sharing how we are applying XP in a remote mode, mainly focusing on Pair-Programing and Retrospectives. The discussion included the difficulties we faced at the beginning and how we managed to solve them. We ended the discussion on both topics by a live demo!

  1. Remote Pair Programming
    • To overcome the problem of time difference between the two cities, the pairs tend to share their calendars as well as an online document with the detailed tasks required to finish the story
    • The navigator might easily lose focus; that is why we try to submit frequently and switch control as much as possible
    • It is more tiring than local pair-programming especially if you have the headset on all day long. We agreed that anyone is free to ask for a break at any time
  2. Remote Retrospectives
    • The whiteBoards were located in Paris, and thus it was hard for us in Beirut to effectively contribute to the meetings. We managed to solve this problem by replacing our the whiteboard with an online Trello boards.
    • Initially, our meetings were held over the phone lacking any visualization of the team on the other side which caused a lot of frustration. To overcome this problem, our IT team installed Visio Conference rooms in both cities!

Here is a short video of the PairProgramming demo we did!

Main message

You don’t have to move abroad for your dream job!“.

Remote work is becoming the trend! The advancement of the collaboration tools and technologies is making it easier for companies to adopt. In the future, you will see more and more developers working from home.

That was our message to the audience!  We concluded that there are three ways to organize your team when working remotely:

  1. Split the team in two if there are enough members in each city
  2. Work in open-source mode if team members are distributed over many cities
  3. Finally, adopt our remote XP practices if it is not possible to split the team in two



In addition to the above two Kudo cards, I received several positive verbal feedback at the end of the session. All that was a sign that our talk was successful!


Finally, you can have a look on our slides here: