BCS SPA Meeting

I read Kent Beck's Extreme Programming Explained in 2000, and it really fired me up. Project manager after project manager looked aghast as I raved, "The software is the design". Colleagues looked shifty when I mentione Pair Programming (I wear a beard, so I knew it wasn't my aftershave). Consequently I've never actually done any XP. However, I am Test Infected: I think Test First coding is the single most useful programming technique in my arsenal.

So it was mainly out of academic interest that I attended this month's BCS SPA session to hear Rachel Davies present an overview of the second edition of "eXtreme Programming Explained". There's been some re-arrangement of the furniture - the XP principles are now explained in a mind-map rather than that confused network diagram, some of the practices have been re-named - but there doesn't seem to be that much that's new.

The only new practice is something called the Informative Workspace, which is basically a visual plan of the project's progress, perhaps implemented as Stories on index cards pinned to the wall. Anybody who is interested can immediately see what the project has achieved and what is yet to be done simply by walking into the project room and looking at the wall. This is another example of the use of low tech in our high tech industry; like using the Hipster PDA instead of a Palm Pilot, the Informative Workspace works precisely because it isn't a computer-oriented approach. After all, whose first action on receiving the latest version of their project's plan in MS Project isn't to print it? Even though it comes out in an eye-wateringly small font (despite printing on A3).

There are some refinements. Simple Design and Refactoring have been amalagmated into a single practice, Incremental Design. Metaphor has been dropped, because hardly anybody used it. Some of the wackier names and concepts (Velocity, the Planning Game) have been renamed to make them more generally acceptable.

In fact, the main thrust seems to be towards making XP less, well, less extreme. The practices are graded into Core and Corollary sets. The practices are optional, in that we can now be doing XP even if we are not using all ten core practices. It's a bit like when SSADM version 4 came out: we can now tailor the method to the needs of our current project. Although I suspect we can't be XP if we're not doing Test First Coding, Pair Programming and Incremental Design.

There is a greater emphasis on continuous validation of the built software. We should always be ready to ship. So, not only are we supposed to test all the time but we are exhorted to do continuous integration all the time. Consequently the automated build and automated integration tests need to run in less than ten minutes. Daily builds have been replaced by Daily Deployments. That's right, into production with new code every day! To me this suggests that Kent Beck hasn't had much experience of dealing with FM-ed shops, where the change control process generally takes four-to-six weeks. In fact XP is still aimed at very small projects. Apparently there is a chapter on scaling XP to large projects but it basically consists of splitting one large project into many small projects, which doesn't seem like a satisfactory solution.

Down the pub afterwards someone remarked that lots of XP is simply obvious good practice and the rest is very dubious. Of course everybody thinks that about XP; if only we could get everybody to agree on which fifty percent of the practices are common sense and which are pants we'd be laughing. My colleague Paul O'Connell reckoned that XP is the product of an industry which has too many programmers and not enough engineers. So I held up my hands as an historian and we had an interesting discussion about the impact of feudalism on Japanese society.

By the way, given that XP is so keen on Pair Programming how come Kent Beck is the sole author of the book?