You are here: Foswiki>SE Web>ResearchHome>PairProgrammingHome (10 Oct 2024, Verversl98UserTopic)Edit Attach

Pair Programming Group

This is the homepage of the Pair Programming research group at the Free University Berlin. We are part of the Software Engineering Group in the CS department.

For more information, please get in touch with Linus Ververs or Lutz Prechelt.

Goals and Approach

  1. Our goal as software engineering researchers is to understand pair programming in such a way that we can advise practitioners how to use it most efficiently.
  2. We propose that the only way to obtain such understanding is to understand the mechanisms at work in the actual pair programming process.
  3. This understanding must first be gained in qualitative form before we can start quantifying.
  4. We perform such investigation based on Grounded Theory Methodology (GTM), working from rich sets of data (full-length audio, programmer video, and screen video of pair programming sessions).

Some Results in a Nutshell

  • Pair programming (PP) does not just ‘work’ because two software developers sit next to each other. Rather, developers can be more or less skilled at pair programming. We characterize two elements of that skill that are independent of software development skills: Maintaining Togetherness and keeping an eye on Expediency. There are possibly more elements to be found.
    See Two Elements of Pair Programming Skill.
  • Maintaining Togetherness between the partners leads to productive Focus Phases, while low Togetherness leads to Breakdowns in which the partners make no progress.
    See Qualitative Analysis of Knowledge Transfer in Pair Programming. Chapter 6: Process Fluency and Pair Togetherness.
  • The expert/novice discrimination used in much existing PP research is not useful. One must consider task-specific knowledge and discriminate S and G knowledge:
    • S-Knowledge: System-specific knowledge includes requirements, overall architecture, detailed design structure, test/build infrastructure, defects, idiosyncrasies, implementation gaps, etc.)
    • G-Knowledge: Generic software development knowledge (programming language details, design patterns, development tools, and technology stacks, etc.)
  • The overall knowledge transfer dynamics of all PP sessions follows a single pattern: Synchronize S knowledge, acquire needed S knowledge together, possibly transfer G knowledge. There is plenty of evidence that differences in S knowledge differences are more important than those in G knowledge: S needs are addressed first, more knowledge transfer is concerned with S knowledge, resolving S need is more often mandatory, and S knowledge transfer is the type that pairs are more skilled with. General programming experience (e.g. Junior / Senior) differences are overrated.
    See Explaining Pair Programming Session Dynamics from Knowledge Gaps and Qualitative Analysis of Knowledge Transfer in Pair Programming. Chapter 11: Session Dynamics.
  • There are more roles in pair programming than the two roles typically defined in the literature. Participants fulfill more different, conceptually separate functions than only the commonly described and hopelessly overloaded driver and observer (or navigator) roles.
    See Liberating Pair Programming Research from the Oppressive Driver/Observer Regime.

Publications

Available Thesis Topics

See ThesesHome for available thesis topics. Contact us directly for further ones or to talk about your own ideas.

Teaching

SWTIDSR
Edit  | Attach | Print version | History: r25 < r24 < r23 < r22 | Backlinks | View wiki text | Edit wiki text | More topic actions
Topic revision: r25 - 10 Oct 2024, Verversl98UserTopic - This page was cached on 01 Feb 2025 - 04:40.

Freie Universität Berlin, Institut für Informatik