Dave Rooney shared a link today to a July 1996 article in CrossTalk: The Journal of Defense Software Engineering by Dr. Randall W. Jensen, titled “Management Impact on Software Cost and Schedule.”
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.
Tags:
software development,
Extreme Programming,
two-person teams
Programmer, husband, father, singer, guitarist, tinkerer, reverse engineer, strange, and living in New Jersey. 
I tend to shun “extreme” programming. Nature abhors extremes. Extremes are destructive. Extremes are never good. Look at the injury rates among practitioners of extreme sports for further reference.
eXTREEMEEEEE programming isn’t even anything new, despite its creators’ claims to the contrary. It’s standard project management with a new name, a self-help get-rich-quick feel, and tons of exuberant Xs everywhere. The so-called new methodologies seem to have been ripped off from the group that wrote all the code for the space shuttle or any other group that writes software where a bug literally means somebody’s death.
This isn’t to say that Xtreme programming’s teachings are wrong. On the contrary, setting realistic goals, testing, and eliminating overtime does wonders for ensuring bugs are kept to a minimum. In fact Xtreme programming is one of the few programming methodologies that Gets Things Right by stating that it is more about organization and process management, not about mangling programming languages.
Still, one can’t help but notice that Xtreme programming takes things to an extreme. It’s most vocal adherents are indistinguisable from religous zealots. They shun those that take a lightweight form of XP, which I suppose would best be called NORMAL programming. Taking anything to extremes is nothing more than being inflexible and irreceptive to change. While it is claimed XP can be changed when necessary, altering the rules turns XP into something else.
Look at it this way. When has anything with exuberant Xs or the word extreme been anything but rehashed garbage or marketing hype?
Also, note that one of the key components of Xtreme Programming, the two man team, is over thirty years old. “Created eight years ago” my ass.
I would like to point out that in the article, programmers were called by the correct job title (programmer) and that they were referred to as “individuals” and “persons”. This is because in the old days, half the programmers were women. You can’t assume “two-man team” – that’s not how it was. The field was not sexist in the old days. I know – I was there. We weren’t called nerds, either. We were professional people. The current nerd/young man image for the profession is so stifling it makes one feel strangled.