Pair Programming

I've only had the opportunity to sprint at Plone conferences and this was already a profound experience. I have been a believer in extreme programming long before I attended Plone conferences but never found a way to implement it in our own company. Mostly because it seemed really difficult to map the disciplines of extreme programming, especially pair programming, to an environment where you have to manage multiple projects at once. We eventually found a way to do it, and given what we have learned in the last couple of months, I don't think we will ever go back to our previous way of working.

Before I explain what we did, let me explain how we used to work and what the challenges were. We are a team of eight developers and in the past we simply took all the projects that we were involved in and divided them up amongst the developers. So if we were working on 4 projects at a time, we would assign about two developers to each project, depending on the size of the project of course. For a given project, we further subdivided the tasks and assigned them to developers working on that project. In this scenario developers didn't work together on tasks, they simply tried to complete the task on their own in the shortest possible time. An important thing to take note of is the fact that all our developers are contracted to do development and were not employees earning a salary. This arrangement worked well for our team of developers who I believe likes to think that they are independent knowledge workers and don't have to work for a boss. Simply put, I call this the model of the individual contractor.

Although we have always been very effective in getting the job done, I have never been extremely happy with the quality of code that we produced. Even in cases where experienced developers produced code to solve particular complex problems in a way that worked and satisfied the customer, this code was not of the same quality as what would have been produced if we were pair programming. In my definition of quality code, I rate simplicity and the code's ability to communicate to the next developer working on it, the highest. It is these qualities that make it easy and fun for developers to work together.

Beside problems with quality, I found that I didn't get enough feedback from individual contractors on how long it took them to complete certain tasks. As a result we didn't have the required information to quote more for complex tasks on future quotes.

Other problems were:

• You can't effectively rate the experience of developers while they are working on their own.
• The risk of maintaining a product is very high when too few developers work on it.
• Knowledge transfer is low.
• Developers did not talk enough about design before coding.
  

I could go into a lot more depth discussing problems with the individual contractor model but you probably know them already. I should emphasize that in my opinion, if you are not doing pair programming, you are following the individual contractor model even if your developers are full-time employees.

So five months ago we decided to change how we worked. Besides deciding to do pair programming we decided to put the whole team on a single project at a time. At this time we were still contracted to do development on multiple projects so we decided to simply schedule them in sequence instead of doing it in parallel. When we compared our schedule for projects where only two or three developers were working on them in parallel, to a schedule where we worked on these projects in sequence, we realised that we will still complete all the projects in time. For example, you might schedule 3 months for 2 developers on a thousand hour project, but you could wrap up that project in a month if you put a whole team of 8 developers on it. We took a big risk to change our way of working, but it absolutely paid off.

We have a team with both experienced and inexperienced developers and the pace at which novices learn while driving is remarkable. The most profound change that has come about is that developers now have to talk about the design and architecture of the code a lot more and they have to motivate it to each other before coding. In the past even experienced developers would often code to get the job done. The feedback loop on the complexity and duration of tasks is a lot smaller. I know almost immediately now when we have underquoted on a tasks. In the past I probably never found out that a developer took 2 days on a task we quoted 1 day for.

Most good developers will agree that coding is design and good design communicates. It is difficult to write code and design at the same time, or write code while thinking strategically about the code that you are writing. It is completely impossible to write good code without communicating. This is why pair programming works! And it works not only in the more relaxed environments offered by sprints, but also on projects with tight deadlines and demanding customers.