After reading Mark Wilden’s tale of Why he doesn’t like Pair Programming I have spent some time reconsidering my Questions about Extreme Programming.
In the book I let Pair Programming off lightly, not fully addressing the dark side of pair programming that Mark addressed. Yes, chapter 9 is called Working at this intensity is hard, but I did not point out that after a full day of pair programming most developers are not in a fit state to do more work. XP requires a 40 hour work week so that the developers can recover from the pair programming.
Other problems I have noticed with Pair Programming
- Exploration of ideas is not encouraged, pairing makes a developer focus on writing the code, so unless there is time in the day for solo exploration the team gets a very superficial level of understanding of the code.
- Developers can come to rely too much on the unit tests, assuming that if the tests pass then the code is OK. (This follows on from the lack of exploration.)
- Corner cases and edge cases are not investigated in detail, especially if they are hard to write tests for.
- Code that requires detail thinking about the design is hard to do when pairing unless one partner completely dominates the session. With the usual tradeoff between partners, it is hard to build technically complex designs unless they have been already been worked out in a solo session.
- Personal styles matter when pairing, and not all pairings are as productive as others.
- Pairs with different typing skills and proficiencies often result in the better typist doing all of the coding with the other partner being purely passive.
Having said all of that, pairing is still a good way to show someone else around a codebase, and pairing is definitely useful when debugging code - the second pair of eyes definitely helps.
Questions about Extreme Programming that are still open
Overall I still see XP as a fairly niche methodology, as there are few projects that it is really suited for. The constraints of XP are fairly rigid, and although many projects have tried to replace the onsite customer with systems analysts, the decision cycle is definitely longer when the analyst is in the loop.
The key problem that XP projects face is that there is no real compelling case for using XP. Yes, some developers like it, but more for the Unit Testing rather than any other part, and the testing aspects can be replicated in any other approach to software development. I still think that the most useful parts of XP can be applied in other contexts.
Overall, although my questioning of XP was not well received at the time, I think it has stood the test of time well in that eight years on,XP is approaching the status of a footnote in software development history. Yes, it helped to motivate the Agile Alliance, but these days I see more projects trying Scrum than XP, and while some of the XP practices are here to stay, it is hard to point to any software that was developed using XP and state that it will stand the test of time.
Yes, many of the tools that supported XP practices will stand the test of time, but most (all?) were not developed as part of an XP project, instead they were solo projects undertaken to assist an XP team in one way or another.
In summary, although Questioning Extreme Programming is now outdated in that it refers to an earlier incarnation of XP, I still stand behind the claim that while it was an interesting approach to software development, it is not applicable to many projects, and the current versions of XP have similar problems. The ultra-light weight approach to software development that tries to put developers first does not work all that well in a corporate or entrepreneurial setting.