Home
Courses/Training
Articles
Clients
Approach
Technology
Associates
Contact Us
Links

Pair Programming and Quad Programming

Abstract

Pair Programming is one of the key practices of Extreme Programming. Pair Programming is when two people sit side by side next to a single computer to code an engineering task. Quad Programming is with 4 people in one room with a projector. This articles discusses experiences of both Pair Programming and Quad Programming.

Overview of Pair Programming and Quad Programming

Pair Programming is when 2 developers sit at one computer to complete an engineering task. One person is the ‘driver’ who types, and the other is the ‘navigator’ who monitors the broader picture of what they are building (design aspects) and manages the development road map. The roadmap is a list of tasks that need completing to finish the task. You can think of it as being similar to rally driving. The driver is very focused on the immediate task in hand, like driving around a corner, whereas the navigator is checking out the road ahead, planning tasks, and ensuring the driver is going in the right direction.

Quad programming is when you have one driver and 3 navigators and everyone sits around a computer which is projected onto a screen. Quad programming is good for team training, particularly around new architectural areas when they are introduced.

Benefits of Pair Programming

Design problems are caught earlier by the navigator, rather than letting a single developer go seriously off track and build all sorts of wonderful stuff that no one wants! Bugs are caught earlier simply because you have two people looking at the same screen. On the whole the quality is significantly higher because investment is made in quality assurance (before things are built), rather than quality control (after things are built). In the short term studies have shown that it takes 2 developers 2 thirds of the time to build something that would normally take one developer to build. In theory, although no large studies have been done, due to the quality gains early on, the overall cost of development using Pair Programming is less than that if the tasks were single programmed.

Who To Pair Together

There may well be certain types of individuals in your team, ranging from students to experts. I would describe a student as someone who is knows syntax well, but not design too well. An expert knows the syntax and is a good technical architect and designer.

Expert Navigator, Expert Developer

A good pairing. Whilst the one expert is busy typing in the current thoughts for development, the other expert cant sit back and think about the overall picture. They can also give the code a once over to see if any obvious bugs have been injected. The perfect pairing with good productivity gains.

Novice Navigator, Expert Developer

Bit of a waste of time this one. The navigator spends all their time trying to grab the wheel, and get involved with the driving, whilst struggling to come up with anything useful in terms of design. They can send the driver all over the place and they often fail to even draw a road map of where they should be going. It results in the driver having to do all the navigation and development, whilst at the same time teaching the navigator why they have done it. Swap the roles around. Or, do detailed design on a whiteboard beforehand so you have a clear road map written out.

Expert Navigator, Novice Developer

This is the best way to train new developers on the team. The expert navigator needs to be careful though not to simply pull the novice developers strings and literally tell them what to type. If all the navigator does is focus on syntax then they aren’t navigating and the pair programming is not as productive as it could be. The expert needs to be a good communicator and teaches in this patient role.

Novice Developer, Novice Expert

Strongly advise against this. A complete waste of time. It is the blind leading the blind. Both will be focused on syntax rather than design issues and refuctor the existing code base. [Refuctoring = ruining the internal code base of the system when adding additional functionality. Also known as introducing code smells.] The developers may well get the development done but are unlikely to implement the functions of the tasks in the correct areas of the architecture. They will also not spot opportunities to refactor. The moral of this story is don’t have more than half your XP team as novices. If you do, then forget XP and do big model up front.

Experiences Of Quad Programming

This section explains my experience of using Quad programming as a means to train the team and also build a solid foundation on which to base further development.

We employed an architect to develop an architectural spike (prototype) for the presentation architecture of the system. We did three iterations before agreeing on a strategy. The spike proved that certain designs were feasible but the prototype code was by no means production quality code and wasn’t built using Test Driven Development [Please take note project managers in a hurry!]. It wasn’t intended to be. At that point I decided to try Quad Programming to code the first user story with the entire team.

The motivations were:
  • Everyone in the team could learn the proposed presentation architecture.
  • Everyone in the team could learn how to write tests for proposed layers of the architecture.
  • The architecture was single person programmed, and three extra pairs of eyes would add additional quality to the design.
  • We wanted to get very good quality first time, as a good foundation to build on.
  • It needed to be written 100% test driven to ensure it was fully testable.
We built the system one test case at a time until we had built the first user story, albeit stubbed out with mock objects at the mapping/persistence layer. The code was written 100% using Test Driven Development , without a single line of code being written without a failing test driven.

It took 4 people 2.5 weeks to build it whilst locked in one room with no distractions, one PC, and a projector. There were around 1000 lines of production code and 900 lines of test code with 104 automated tests which ran in just under 2 seconds.

This was approximately 3 months ago. Unfortunately the team reduced to 3, but since that time the application now has 8,500 lines of production code, and 7,500 lines of test code. The tests now number 304 and take 14 seconds to run a full regression test of the web application.

What did we learn from Quad Programming?

The quality of the code was second to none. Not a single design got through without serious debate. On occasions we spent an entire day on the code base and produced less than 100 lines of code. Other days we would make a decision and just hammer the solution out. The code was the highest quality any of us had ever seen. Although we had to make enhancements as the application progressed, the investment in getting the separation of concerns right in the first place made the enhancements that much more easier.

The whole team knew why we had built what we had built. As often in design sessions there is enormous value in the discussions had in getting to the result, rather than the final result itself. The ‘why’ has tremendous value in addition to the ‘what’. These benefits are not realised with the ‘big model up front, throw it over the wall approach’. Thus, in further discussions about design, everyone knew what the responsibilities of each layer were. It simplified the decisions later on about where to place responsibilities in the code. I suppose this is where the XP metaphor is supposed to help.

Due to the intent of the design, the speed with which we could fully regression test our web application was much higher than in previous projects. Previously we had automated the testing of the application by automating the IE browser via a plug in we wrote for NUnit. This proved slow in the past taking up to 25 minutes to run. Now, because of our new architecture, we could plug tests in at any point and simulate http requests using our mock httpContext. Granted, this wasn’t a direct result of Quad Programming per se, but more as a result of having myself, ‘Mr Test Infected’, with a great architect to realise my testability ambitions.

In terms of the pace of Quad Programming versus Pair Programming, Pair Programming is faster, but you quality is lower. In the short term I would suggest the payback is from the quality of the code base and also from the education it gives to the team. Long term as an activity I don’t feel it would be justified unless a major piece of architecture was added to the system. I’d advise staying with Pair Programming once the team understands the architecture.

Debugging during the sessions was sometimes tough, since you would get 4 people shouting out ideas at the same time. This was similar when we approached a problem where it was obvious the design was wrong. Again, all 4 people would try and get their point across at the same time. It required some mediation between those in the team who were more assertive than the others. It was very easy for 3 people to switch off and think about their solutions to the problem whilst the other person spoke into space thinking they were being heard. Again, this required some self mediation.

Another aspect to watch was ensuring that everyone in the team understood why certain decisions were being made. Since, that was one of the main reasons for exercise. This meant careful watch of the less design aware team members to make sure they understood. Often the experts got carried away and wanted to rush off, and they needed holding back so the others could understand.

Still, on the whole an extremely worth while exercise that has benefited the whole team. I would strongly recommend the approach to any team attempting a Greenfield project using XP

Closing Comments

Good luck in your developments and roll on XP!

Dave Chaplin

All content © Byte-Vision Limited 1997 - 2004