Article: Pair Programming

From Software Business Community

Jump to: navigation, search
This is an article in the
Encyclopedia of Software Business.
Main page
[+] Encyclopedia articles


Pair programming

Pair programming (PP) [1][1] is a method of programming in which two people work together at one keyboard. One person, "the driver", types at the keyboard. The other person, "the observer" (or "navigator") reviews each line of code as it is typed, checking for errors and thinking about the overall design Some benefits of PP include: better code (simpler design, fewer bugs, more maintainable), higher morale, shared knowledge throughout the team (both specific knowledge of the code base and general programming knowledge), better time management and higher productivity.

This Encyclopedia article is a STUB, implying that it missing most of its content.
Please help the community by contributing your expertise and experience to adding content to this article.

Contents


Pair programming tasks

A PP task could be any development activity for example analysis, design, programming, testing e.t.c. Working together is achieved by splitting and switching the roles of the developer into Navigator and Driver role periodically. The couple works in continuous collaboration and each of them must understand and participate in solving the task at hand.

Advantages of PP

The benefits of PP include:

  • software quality improvement as a result of intensive effort
  • continuous peer reviews lead to less defects and better design
  • because of sharing resources, collective code ownership and working together, knowledge is easily transferred and shared.
  • PP is also good for teaching and mentoring new and inexperienced colleagues, this in turn leads to less dependency on individuals with specialized skills.

Some beneficial human factors of PP include for example:

  • discipline
  • high job satisfaction
  • trust and teamwork morale
  • in PP, pairs finish work faster, this leads to more accurate effort estimation
  • as opposed to the software engineering (SE) paradox that adding more people to a late running project makes it more late, using PP, adding new people reduces the project duration

PP and people

Pairing makes people work differently[2][3], some factors that lead to above mentioned benefits include: Pressure i.e. people work harder and smarter in order to contribute to solving the pair’s task they concentrate more, this leads to the fulfillment of Parkinson’s law of meeting explicit deadlines. Overall, this leads to an increase in the use of prescribed practices. Solving problems together leads to better solutions because both people bring their own set of skills and tend to evaluate more alternatives as a pair. As pairs learn the problem domain, how to use tools together etc, they both learn and gather in-depth knowledge of the subject. Courage is another factor, in PP people can ask questions, discuss problems more openly and actively seek help when they are stuck as opposed to Solo programming. As continuous review is the practice in PP, defects are often noticed early in the development stages and hence fixing them is much cheaper. Because verbalizing (thinking aloud) often helps to solve programming problems, it is encouraged in PP. Some of the greatest benefits of PP could be seen in big projects e.g DSD projects where training time is negligible as compared to the practice’s long term benefits. Significant reduction in bugs and maintenance costs is also observed as well as increase in the quality of the product. Solving of complex tasks is often made simple by pairing expert programmers with juniors or intermediates. Other benefits could be realized by using PP along with specialized development tools and other agile software development methods like Crystal, Feature Driven Development, Extreme Programming, Scrum e.t.c.

Disadvantages of PP

The costs that go with the adoption and practice of PP include [4][5]:

  • increased effort on task level
  • inefficiencies when launching and learning PP due to mistakes and time needed for getting partners to know and get acquainted with each other.
  • intensive nature of working due to increased effort on task level leads to exhaustiveness
  • scarcity of studies and information about PP is another adoption and implementation hindrance especially from the industry.

PP preconditions[6][7]

Some practicalities that need to be taken into account before adopting PP include answering of the following questions: which tasks would be performed using PP, who proposes the use of PP, who pairs with whom, how often will roles be switched, infrastructure choosing etc. It’s recommended to have good desks, white board for illustrating ideas, common IDEs, coding standards etc. Control the noise from PP by setting special PP rooms, though some PP noise maybe useful to others. Encourage communication between pairs, the driver should think aloud and the navigator should be active. If possible introduce the use of two keyboards and mice for easy communication and participation. Choose pairs carefully taking into account individual needs and skill level. Avoid no ‘flow’ by encouraging pairs to concentrate and achieve joint flow as PP reduces mental blocks (opposite of flow). Take into account those who can concentrate better when alone.

Indispensable PP tips [8][9][10]

Pair Seniors with juniors/intermediates, set time for seniors to do their own work. Use PP for solving complex tasks and knowledge transfer, set time for PP, use PP in place of formal inspections and consider having a limited number of workstations (but provide enough for the job), setup company policies with PP in mind.

Industrial application of PP

Beneficiaries of PP and other agile software development methods include big global companies like:

Related reading

References

  1. ↑ J. Vanhanen. Pair Programming. TKK, SoberIT. 2008
  2. ↑ R. Pressman. Software Engineering - Practitioners approach. Wiley, 2006
  3. ↑ G. Larman. Agile and Iterative Development: A Manager's Guide, Addison-Wesley Professional. 2003
  4. ↑ D.Turk, R. France, B. Rumpe. Limitations of Agile Software Processes. Wiley. 2006
  5. ↑ D. Wells, L. Williams. Extreme Programming and Agile Methods. XP/Agile Universe. 2002
  6. ↑ D.Turk, R. France, B. Rumpe. Limitations of Agile Software Processes. Wiley. 2006
  7. ↑ D. Wells, L. Williams. Extreme Programming and Agile Methods. XP/Agile Universe. 2002
  8. ↑ R.C. Martin. Agile Software Development: Principles, Patterns and Practices. Prentice Hall. 2002
  9. ↑ G. Larman. Agile and Iterative Development: A Manager's Guide, Addison-Wesley Professional. 2003
  10. ↑ D.Turk, R. France, B. Rumpe. Limitations of Agile Software Processes. Wiley. 2006
Retrieved from "http://www.swbcommunity.org/swbc/index.php/Article:_Pair_Programming"