Pair Programming

I l @ ve RuBoard

We first heard about pair programming ”one of the pillars of XP ”at a conference a couple of years ago. It sounded like a great idea, but we just couldn't believe that the developers we worked with would really agree to try it. However, after staying late one night to work on a defect report with a couple of programmers, one of us had a revelation. There we were, a project manager, an HTML programmer, and a Java programmer trying to make a page load and print the same way in Netscape and MSIE. After spending a few hours working on the problem separately, we ended up huddled around a computer, each making suggestions and each taking a turn at the keyboard. Within 30 minutes we solved the problem and each of us had learned something about the others and our various skills.

Now what if it wasn't just an HTML guy and a Java guy? In Web development there are different skills and knowledge to be shared. Wouldn't it be great if we could expand the pair programming technique to other areas of the project? For starters, imagine how much better Web sites would be if the graphic designers understood how pages are put together and how browsers can limit or expand the implementation of a design?

We started experimenting. First we tried pairing up interface programmers with backend developers. The results we got were what we expected:

• The programmers were happier and the morale of the team improved.

• Everyone learned a lot from his or her partners .

• The quality of the code was improved.

• There was less cowboy programming and more efficient code.

Then we tried to mix up the teams a bit more by combining different skill sets:

• Interface programmers with graphic designers

• Customers with testers

• Testers with graphic designers

• Customers with everyone

Out of each pairing came a better process and interesting results, described in the following sections.

Interface Programmers and Graphic Designers

Style documents were designed to define the same information that the CSS defines. The graphic designer/interface programmer pair could skip developing and then translating them into CSS by developing the CSS together. This gave the graphic designer more creative control and helped him understand the possibilities, making the design and interface better. We found that the CSS made a much better style document than anything we had created before.

Before the pairing, the graphic designer would create paper prototypes of the site, which became a set of instructions for the interface programmer. Yes, that meant a mockup of every page of the Web site, which the interface programmer would translate into XSLT. This would work only if the designer had a thorough understanding of the application's functionality and data and what the browsers supported. Instead, the graphic designer and interface programmer worked page by page, taking the XML schema, content, and tasks to develop the XSLT. ^[7] This change once again gave the graphic designer a better understanding of what was possible and improved the quality of the design.

^[7] See Chapter 10 for a full discussion of XML and XSLT.

As for customer approval, we found it was easier to create a PDF of the Web site for the customer than to print each of the Photoshop files that made up the mockup. It was also easier to make changes and keep documentation up to date.

Customers and Testers

Many customers we worked with had no experience writing acceptance criteria. By pairing them with testers, they became more comfortable with the process and hence created better criteria. This pairing also helped the testers develop better acceptance tests.

Testers and Graphic Designers

One of the hardest things to test is something subjective , like the interface to a Web site. That is why math was many people's favorite class in school ”it is either right or wrong. Testers and graphic designers can develop tests for the Web site's layout, colors, fonts, and anything that can be defined. With this pairing we found that the tests developed were much better, and we were able to reduce the number of defects that carried the tag "But check with the designer to see if she wanted it this way."

Customers and Everyone

The more we made the customer a member of the team, the more he got involved in the process and the project and hence the more he enjoyed working with us. He trusted us more ”the programmers weren't just tech guys in a back room he would never meet. He got to work with everyone, state opinions , and learn more about the steps involved in each task. We even started writing tasks that the customer would volunteer for and pair up with the team members on, such as collecting product data.

I l @ ve RuBoard