XP c.2008

In Boston, I attended a session lead by Neal Ford from Thoughtworks.  He shared his company’s experience of applying XP in a variety of domains.  Thoughtworks almost exclusively uses XP on all their consulting engagements.  Here are some thoughts on three pieces of misinformation about the XP community.

Pair Programming

Pair programming continues to remain controversial, but removing it from XP cripples the process.  The main reason is because eliminating pair programming takes away one of the key feedback loops XP is built upon – review of code by a second pair of eyes as it is written.  Having developers pair program increases the concentration, focus and productivity of the team.  I know it is counter-intuitive, but pair programming is one of the main reasons why XP teams make such great improvements in productivity.  Everyone is focused either with the writing code or thinking about how to improve the design.  No one is off surfing the net, killing time on the phone or responding to email – they’re working and working hard!

Kent Beck has clarified his position on pair programming in Extreme Programming Explained (2nd Edition) – not even Kent pair programs all the time! – and it remains very important to the process.  I feel pair programming is so tightly coupled to the identity of XP, that I would find it hard to believe a team is “really” doing XP (as if that really matters to anyone but us process nerds) if they are not pair programming.   IME, if a team says they are not doing pair programming and you dig into the details why, you normally find out they are not working in timeboxed iterations, not refactoring, don’t refactor and on-and-on.  The just took their ad hoc, undisciplined process and labeled it XP.

Documentation

Contrary to what people think they know about XP, good XP teams document their work.  They just tend to use light-weight documents for communicating to themselves, only preserve documents that are useful and avoid the “write-only” (think about it) documents often mandated by process police.  XP teams tend to use a wiki as a living document repository and their unit tests as a specification document built from code examples.   The wiki (probably one of the more revolutionary pieces of software ever created by XP’s “grandfather” and “midwife”, Ward Cunningham) is the place to hold user stories and the details surrounding the stories, preserve design discussions, design briefs and useful design diagrams and a place to maintain strategic and tactical decisions made.  I have seen Confluence be used very well when I worked at a large government contractor, but like anything else in XP, you need to be disciplined about maintaining it.

Code Comments

Code comments are a special form of documentation and are commonly thought of as a “best practice”.  Yes, we want to write comments about why we do something or capture the domain rules, but we do NOT want to write a comment telling me what the code does.  IME, if you need to write a comment in your code, then you have failed to express yourself clearly in your code.  Class, method and variable names all should be easy-to-understand and expressive.  When you read code, it should read like a blog entry, i.e. be coherent and comprehensible.  Document and comment your API, but writing JavaDoc style comments for code that will never been seen by the outside world only gets in the way of refactoring the code later.