According to Laurie Williams,
pair programming is a style in which two programmers work together at one
computer, collaborating on the same design, algorithm, code, or test.
In pair programming, one will be
the driver. The driver is responsible for typing the codes or creating
the design. The other will be the navigator, who has a lot of tasks to perform;
one is to carefully observe the work of the driver. The navigator
has to look for defects or errors which include syntax errors, typos, calling
wrong methods and the design implementation.
The good thing about pair
programming is that there is a constant brainstorming and analysis. The navigator
has the objective view on the direction of the work since it has limited involvement
in the design, code, and algorithm. The pair should also discuss on alternative
solutions to the problem and on what’s happening on their work. Discussions and
chatting could also help improve your pair. Roles can also be switched between
your pair.
Pairing does not only happen in coding.
The team can have pairs on design, debugging, testing or when the problem is
complex. The idea is working with a collaboration of a partner at any phase of
software development.
The down side is when the
navigator is quite which would have your discussions not that effective. Another
challenge is the level of expertise. For some programmers, they concern on
their concentration when working with others which could slow down them down
and with some slow or with low self-esteem programmers, their concern is that
they are not adequate or of much help to their partner. In the industry,
companies would think that it would be an additional cost as two programmers
work in one task and the number of output is also affected.
Personally, I am into pair programming. If we start practicing this in the academe, adjustments and adaptation wouldn’t be a problem. And challenges on communication, level of expertise and coordination won’t be also be a problem. In terms of company cost, companies should consider paying high quality software and employees that work harmoniously.
Reference: (This has no format.)
Williams, Laurie. "Pair Programming". Chapter 17, "Making Software: What Really Works and Why We Believe it", O'Reilly.
Accessed last: December 12, 2012.
Personally, I am into pair programming. If we start practicing this in the academe, adjustments and adaptation wouldn’t be a problem. And challenges on communication, level of expertise and coordination won’t be also be a problem. In terms of company cost, companies should consider paying high quality software and employees that work harmoniously.
Reference: (This has no format.)
Williams, Laurie. "Pair Programming". Chapter 17, "Making Software: What Really Works and Why We Believe it", O'Reilly.
Accessed last: December 12, 2012.
