This past Thursday we met up at Far from the Madding Crowd again, to discuss Kent Beck’s Extreme Programming Explained. The intention was to see how the second edition had changed from the first, as a couple of us had already read them both once, and found there to be something of a change in tone. In attendance were Adrian, Steven, Miquel, Chris, Tim and Graeme.

Adrian kicked off proceedings by suggesting that in re-reading the second edition, he had found it very different to his first reading, in that it didn’t seem as different in content as he had thought. The tone however was what was different, possibly pitching the ideas to a different audience. Some of whom might have for instance “tried paired programming, and it doesn’t work”, and thus dismissed Extreme Programmings concepts altogether, where they may still have much of value to learn from it. Chris agreed that it had a more relaxed done, possibly even less evangelical. He pointed out that Beck shows examples of where projects he had brought XP to had failed, and worried that if he can’t persuade people to work more fully with it, who can? Steven felt that the practices described were the same, but that it was the values and principles that were now more muted.

We then looked at some of the inconsistancies we’d come across. Chris mentioned the example about planting marigolds next to strawberries. “Planting them together is a practice. Companion planting is the principle” (P15). He felt that surely this was the same thing. Miquel showed us the concepts of Team Continuity (P63) and Shrinking Teams (P64), and noted that keeping a team together was contradicted by the idea of shrinking a team when a member was no longer needed for an exact task. Graeme also observed that this went against the principles of safety and job security that were exposed earlier by Beck. Adrian added that he had never seen shrinking teams work in action, which Steven agreed with, having seen in his experience that projects always expand to meet their resources.

We then discussed the practises of XP. “Practices are a starting point only”, Chris pointed to, which seemed a less rigid approach than previously taken. Adrian wasn’t happy with this, and felt that the starting point was to define the values. We also looked at the statement that energized work “can’t be proved with science”. Miquel pointed to page 59, where it said that it should be possible in some way to make it more effective. He questioned if Beck proved it, is XP a silver bullet? Graeme added that he was disappointed that there were no examples from the XP community in the book, which may have added to his proof somewhat. Miquel added that without proof, it is hard to persuade a boss that less hours can be more productive.

There was then a more general discussion of the two books. Adrian felt that the tone of the first edition was almost “this book can improve your life!”, whereas the second was somewhat more muted. It also seemed to suggest that the second had less work to do in persuaded the wider developer audience of some of the principles, that alternate ways to the waterfall method of development were generally accepted, if not practised. He particularly liked the idea of having a quarterly cycle atop the iterative cycle, this brings a different perspective to the process, lets you look at the wider picture. Chris had found the first a revelation, that finally there was another way. Tom said that he was slightly sceptical of the test-driven design style, that in particular he sometimes need more code just to know what results he will get in the end. Adrian pointed out that he had had good results with using unit tests in Perl. Miquel added that individual tests should ideally be no more than 5 or 6 lines long, and that perhaps if your tests are too long, that they aren’t always the right tests.

The next topic was estimating and timings. Chris didn’t quite see why Beck had changed from using points in estimations to using time, as if the timings on a project changed, it was much more work to change all the timings, whereas with points it is just a matter of changing the budget, and leaving the same points values on all the stories. Adrian’s present role involves him having to estimate in time, and he did feel he was more accurate with it. Tom’s experiences were that points were more accurate for him, he said that when they were converted into times they looked wrong, but would often be very accurate. Miquel moved onto the allocation of stories, and warned that he felt people would tend to cherry-pick stories, and that the last-picked stories could be the worst. Steven pointed out that different people were suited to different tasks, and that choosing the most suitable for each individual may be better anyway. We then compared some of the build processes we used.

There was then some more general discussion about points in the book. We looked at the Primary and Corollary practices, with Adrian being surprised that real customer involvement was considered corollary. The corollary practices seemed to be the harder to sell to none-XP people, and also harder to implement. It also seemed that problem-solving using the 5 whys method seemed a bit random, although Adrian pointed out that the message may well be to question more intelligently. There was a general feeling that this also improved where the whole team was involved. Steven noted that he felt as he developed more as a programmer, he learnt that the team beyond the programmers was more important. Miquel said that maybe XP has application to disciplines other than just programmers. Adrian agreed, and said that it was better to get the other roles working in an XP manner if at all possible.

In conclusion though, we agreed that we had taken a very critical approach to reading and discussing the book, and that overall it was very inspiring to most of us.