 In
this sixth article of the series on Extreme Programming, PRADYUMN
SHARMA discusses how two programmers working together on one computer
can enrich a development project
Pair programming, the fifth practice of Extreme
Program-ming (XP) that we discuss here appears as one of the most
unusual of its twelve practices, at least at the first glance. XP
strongly advocates pair programming as a very important aspect of
agile software development. A lot of code is written by two programmers
working on one computer.
Before we look at it in more detail, and understand
how it works, and how it benefits a project, let me first make it
clear that you do not have to write all the code in a pair. Some
programming tasks are very simple—even trivial—and these
do not require two heads to work together. For example, if you are
designing a screen layout using an interactive editor, you may not
require another person to pair with you. But much of the code involving
non-trivial tasks, such as business logic, flow of operations, database
access, etc, is implemented by two programmers working together
as a team.
Swapping of roles
When two programmers pair up for a programming
task, they would normally swap their roles from time to time. Initially
one programmer may use the keyboard and do the typing of the code,
while the other programmer may come up with new ideas or alternative
approaches to what is being implemented, think of additional test
cases to be included, keep an eye for possible flaws or bugs in
the implementation, point out any deviations from the coding standards,
etc.
After a while the two programmers may swap their
roles. The second programmer, who was doing more of strategic thinking
so far may have a better idea for the part of the code to be written
now, and therefore, may take up the job of keyboard pounding, while
the first one may try to understand what is going on, and carry
out the tasks that the other programmer was doing earlier.
Pairing is dynamic
 You
do not marry two programmers (either literally or figuratively)
to pair for the entire duration of a project. Pairing changes from
one small programming task to another. Nobody forces from top the
decisions about who pairs with whom for a given programming task.
Programmers in a team know each other and there are no communication
barriers, so everybody knows each other’s strengths and experience.
So when I begin work on a new programming task, I know the relative
complexity of that task, and I know who may be able to help me complete
it quickly and efficiently. And therefore, I request that person
to team up with me.
As Kent Beck says, the rule of the game is that
when you are requested to pair with someone and help, you have to
accept the request.
The advantages
How does pair programming help? First of all,
it helps in spreading the knowledge about every part of a system
to more than one person. There is no significant code in the system,
which has been written or seen by only one individual.
In fact, as other programmers refactor the code
from time to time, either to include some additional functionality
or improve the quality of code, this knowledge is likely to spread
even further, beyond the pair that originally worked on that piece
of code. Thus pair programming promotes better communication among
the team members, one of the key values of Extreme Programming.
Pair programming also brings out better quality
of code the first time itself. When I am writing a program all alone,
I may have many blind spots. I may not realize immediately where
I am making a mistake, I may not pause to think if there could be
a better, simpler or more efficient way of implementing what I am
doing. But when somebody is pairing with me, they may be more likely
to spot any errors or omissions on my part, suggest better alternatives,
think ahead about the general strategy for the program, as well
as nudge me whenever I may deviate from the coding standards. They
may be able to look at the bigger picture, while I may be focussing
on the current part of the code that I am implementing.
By swapping the roles from time to time, the
two programmers pairing together ensure that both of them get to
alternate between writing code some of the time, and doing more
strategic thinking at the other times.
Pair programming also facilitates a smooth and
gradual induction of new members to a team. Initially, they may
pair up with existing developers and may only observe and understand
the structure of a system, and get an idea of what work is currently
going on. They may ask many questions to the other programmers to
improve their understanding of the system. Slowly they will start
contributing by finding errors and suggesting test cases, etc. Grad-ually,
they will reach a position where they can actually make equal contribution
in writing new code or refactoring existing code.
Pradyumn Sharma is the CEO of Pragati Software.
He is a trainer and consultant in the area of Object technology,
Design Patterns, and Develop-ment Methodologies. E-mail: pradyumn.sharma@pragatisoftware.com
|
