June 22, 2003
June 22, 2003
June 25, 2003
8.792.1 - 8.792.6
Is Pair Programming an Effective Way to Learn Computer Architecture? Edward F. Gehringer North Carolina State University firstname.lastname@example.org
Pair programming is a concept where two programmers work side by side at the same computer, writing code jointly. One of them, called the driver, is in control of the keyboard and mouse. The other, called the navigator, observes what the driver is doing and offers advice. It is the driver’s job to write the code. The navigator has a chance to observe the larger picture, evaluating the driver’s code for correctness of design and implementation. Studies have shown that pair programming is very effective. Two programmers can finish a task in little over half the elapsed time that a single programmer takes. And the quality of the code—measured in terms of absence of defects—is much higher.
In the past few years, pair programming has made inroads into industry and into programming courses. However, it has not typically been used in courses that teach subjects other than programming or software engineering, nor has it been used in the analysis of experimental results. This paper reports on an experiment in a combined senior/masters level computer architecture class, using Hennessy & Patterson’s Computer Architecture: A Quantitative Approach as a text. Students were required to implement three projects simulating various aspects of a microarchitecture (cache, branch predictor, dynamic instruction scheduler). Then they engaged in an experimental analysis to find the best configuration in a design space. They were encouraged to pair-program, and data were gathered on their experience.
Pair programming is one of the twelve practices of Extreme Programming (XP), which is the best known of the “agile” software-development methodologies that have gained widespread attention in recent years. Agile methodologies attempt to mitigate some of the up-front design costs of heavyweight methodologies, which expend a lot of effort on design before code is written, and to adapt more gracefully to change in project requirements or scope.
Pair programming  is a style of programming in which two programmers work side by side at one computer, continuously collaborating on the same design, algorithm, code or test. One of the pair, called the driver, is typing at the computer or writing down a design. The other partner, called the navigator, has many jobs. One of the roles of the navigator is to observe the work of the driver, looking for tactical and strategic defects in the work of the driver. Tactical defects are syntax errors, typos, calls to the wrong method, etc. Strategic defects are said to occur when the team is headed down the wrong path — what they are implementing won’t accomplish what it needs to accomplish. Any of us can be guilty of straying off the path. A simple, “Can you explain what you’re doing?” from the navigator can serve to bring the driver back onto the right track. The navigator has a much more objective point of view and can better think strategically about the direction of the work. The driver and navigator can brainstorm on demand at any time.
Proceedings of the 2003 American Society for Engineering Education Annual Conference & Exposition 1 Copyright © 2003, American Society for Engineering Education
Gehringer, E. (2003, June), Is Pair Programming An Effective Way To Learn Computer Architecture? Paper presented at 2003 Annual Conference, Nashville, Tennessee. 10.18260/1-2--11877
ASEE holds the copyright on this document. It may be read by the public free of charge. Authors may archive their work on personal websites or in institutional repositories with the following citation: © 2003 American Society for Engineering Education. Other scholars may excerpt or quote from these materials with the same citation. When excerpting or quoting from Conference Proceedings, authors should, in addition to noting the ASEE copyright, list all the original authors and their institutions and name the host city of the conference. - Last updated April 1, 2015