As a firm believer and occasional practitioner of Extreme Programming (or, “XP”), the article is naturally very interesting. One of the key practices of XP is called Pair Programming, where two people sit at one computer and work on producing the code in unison. It’s very challenging: most software engineers are poor communicators, have social anxiety issues, or otherwise find objection to having to actually work with someone else directly. I’ve found that the biggest objectors to it are those who have never even done it. It is naturally one of the biggest advantages of the core XP practices over all the other agile methodologies popular today. Therefore, it’s no surprise that it hasn’t been done before. What’s surprising is how much earlier than XP it was done: according to Dr. Jensen’s article, it was done in 1975 (!):
Two-Person Team. The two-person (2P) team implements the adage “Two heads are better than one.” When this concept was first implemented in 1975, there was great concern the productivity gain could never offset the additional resource expense. The two-person approach places two engineers or two programmers in the same location (office, cubicle, etc.) with one workstation and one problem to solve. The team is not allowed to divide the task but produces the design, code, and documentation as if the team was a single individual. The 1975 team’s project was a real-time, multitasking system executive of approximately 30,000 FORTRAN source lines. The development team had five 2P teams and a progressive Theory Y type project leader. The traditional development environment, outside the 2P team organization, was typical of most environments. The architecture design was completed in a war room environment. The project architecture divided the development into six independent tasks, with the two smallest tasks assigned to one team. The 2P teams returned to the war room environment during system integration. The team concept appears to have been violated when the project was divided among five independent teams working in their own small war rooms (two-person offices). There were two organizational issues working here:
- The facilities people (known as the furniture police) were not convinced this idea would work.
- The tasks were truly independent. Thus, the minimum team size of two programmers was adequate, and the project proved the significant benefits of teams as small as two people.
Final project results were astounding. Total productivity was 175 lines per person-month (lppm) compared to a documented average individual productivity of only 77 lppm prior to the project. This result is especially striking when we consider two persons produced each line of source code. The error rate through software-system integration was three orders of magnitude lower than the organization’s norm. Was the project a fluke? No. Why were the results so impressive? A brief list of observed phenomena includes focused energy, brainstorming, problem solving, continuous design and code walk-throughs, mentoring, and motivation.
It’s easy to come up with excuses why “this just won’t work” but the reality is, if you instead find equally creative ways to create an environment where your team can do Pair Programming, the measurable benefit will make you wonder why you hadn’t been doing this all along.