Questioning Extreme Programming

David Kennedy writes with the following review of Pete McBreen's new Addison-Wesley title, Questioning Extreme Programming. It's one of the few books which casts a questioning look at the buzzwords and concepts of Extreme Programming; read on to see how well XP fares under McBreen's examination. Questioning Extreme Programming author Pete McBreen pages 186 publisher Addison-Wesley rating 9 reviewer David Kennedy ISBN 0201844575 summary A critical but fair re-examination of all of XP.

In short:

This is bound to a controversial and widely read title -- it is a critical but fair re-examination of all of XP's assumptions and core practices. It provides a much needed comparison of XP with other, less popular, methodologies. Overall, XP emerges favourably, with one serious caveat -- the author concludes that XP is only suitable for a very narrow range of projects, and those that can fulfill all requirements probably stand a significant chance of succeeding using any of the similar methodologies. As with programming languages, there is no silver bullet -- put XP in your methodology toolbox, know when it is appropriate and only use it then.

A couple of interesting specifics:

• The author specifically argues, and I agree, that what the XP literature badly needs is a DSDM 'suitability filter' to advise project leaders as to whether XP is for them.
• In the preface, Kent Beck describes the On-Site Customer role as a team, and not an individual role.

Overall, this is an intriguing and well-argued book. It's based on solid, reasoned arguments, with conservative conclusions drawn based on the evidence. It's a must-read for those interested in XP and other Agile methodologies. The Extreme Programming Series

This is the 8th title in The Extreme Programming (XP) Series from Addison-Wesley, surely the most widely read series on a software methodology ever! (If that isn't achievement enough, XP also made testing sexy again. I hear that accountancy firms are looking for Kent Beck to do Public Relations work ...) For those of you who have been living under a rock for the past couple of years the previous titles are:

• Extreme Programming Explained (Beck)
• Planning Extreme Programming (Beck & Fowler)
• Extreme Programming Installed (Jeffries et al)
• Extreme Programming Examined (Succi & Marchesi)
• Extreme Programming in Practice (Newkirk & Martin)
• Extreme Programming Explored (Wake)
• Extreme Programming Applied (Auer & Miller)

This new addition to the XP library feature a foreword by Kent Beck. This is important as many of the reactionary XP fan-club will not like this book -- it challenges XP, and I am delighted to see this title as part of the series. Beck admits he doesn't agree with McBreen's conclusions, but asks you to read the book and decide for yourself, conceding that the arguments are fair and reasoned. I come from a scientific background and distrust anything except wide open debate, a position many who welcome XP will surely agree with. A book challenging XP can only help persuade people to give it a go, by addressing their fears and explaining how to manage any real risk.

Check your sources

Pete McBreen is the author of the excellent Software Craftmanship: The new imperative, a 2002 title from Addison-Wesley. In it he outlines an alternative to the software factory model behind much of traditional software engineering thinking. He proposes a collaborative model with small teams, where the software coder is seen as a craftsman in constant dialogue with the customer. Sound familiar? It should, this is a cross between a methodology and book of advice for career programmers, and fits squarely within the values proposed by the Agile Alliance, and arguably popularised most by XP.

I highly recommend Software Craftmanship, and can think of few authors who are as well positioned to give an analysis of XP as it currently stands.

What is the book about?

Questioning Extreme Programming does just that -- it's the first title in the series to take a skeptical look at the rise of this popular methodology and question some of the key assumptions. Arguably there was material like this buried in Extreme Programming Examined, but it suffered from a fragmented, detailed view, due to it being a bound set of conference papers.

The author tackles XP in a fair way -- he's extremely excited by the methodology, and it's clearly in accord with his own preferred approach. What he does is tackle each of the XP tenets in turn, questioning their validity, and then moves on the compare XP to other Agile methodologies and asks how XP stacks up against the competition. He also has a look at the common mis-conceptions (from both sides) about XP, and tackles the key arguments against its adoption in the same way.

Let's have a look at the contents to give you an idea of the structure:

• Introduction.
  XP: Hype or HyperProductive?
• What is a methodology?
  
  • What do methodologies optimise?
  • What are XP projects scared of?
  • What do other methodologies consider important?
  • What is important for your projects?
• Questioning the Core XP Practices
  
  • Planning incremental development
  • Truly incremental development
  • Are we done yet?
  • Working at this intensity is hard
  • Is that all there is to XP?
• Questioning XP concepts
  
  • The source code is the design
  • Test first development
  • Large-scale XP
  • Is the cost of change really low?
  • Setting the dials on ten
  • Requirements: Documentation or a conversation?
  • Is oral documentation enough?
  • Playing to win?
• Understanding the XP community
  
  • ReallyStrangeSayings
  • Feel the hostility; experience the joy
  • Transitioning away from XP
• Your choice
  
  • Is XP for you?
  • Do you have a suitable first project?

What's good?

The whole thing. Let's start with the basics, the high standards of the XP series are maintained, with flawless editing and layout. Moving on, the author's position is admirably neutral -- he is knowledgeable about the field, and although he wants to be converted, he argues only from first principles, and only from the evidence. Similarly, at no point did I think he set up a straw man, or tackled the opposing issues in a different manner. I particularly admired the way he avoided polarising issues -- "All models are lies." -- dismissing them as unhelpful in his current investigation. (He points out that much of the fire in the XP debate has resulted from the use of deliberately polarised opinions as a unambiguous goad to further debate within the XP community. Fine within the gang, inflammatory outside.)

The structuring of the book is of particular interest -- the argument could easily sprawl, but is restrained into very short sub-sections, with each section sporting a clear list of summary bullets. As much as is practical, each challenge to a tenet or practice of XP is discussed independently. (This comes across as simple and straight-forward and you may wonder why I even mention it, but I think it's a fine piece of editing and worthy of praise.)

The sections of the book that I enjoyed most were those dealing with the SmallTalk culture that XP grew out of -- he presents an interesting analysis of why XP works within that environment but discusses how that environment is NOT typical of most development. I have some bias here due to my own experience, see below, but had to agree strongly with his contention that XP is weakest when it comes to team resourcing, and the on-site customer. In particular, he argues that while XP restores dignity and human rights to the programming team, it does so at the expense of the poor frazzled customer. Similarly, he argues that the pre-conditions for XP, in terms of the programming staff, are so high that almost any methodology could be made to succeed with that team.

Don't get the impression that this is a negative work -- it's not. Most of XP emerges intact, and I felt that the author genuinely wanted only to restrain people from adopting XP in inappropriate situations -- not to persuade people to avoid XP. In doing so, he actually protects XP from bad press due to teams failing when trying to adopt XP, them blaming XP itself, rather than their own inappropriate circumstances.

What's bad?

Er, not much. He sort of pulls in some material re Open Source early on, but fails to particularly build on that comparison, moving instead to a comparison of Agile methods in closed source circumstances. This is a feeble objection -- but really, it's all I've got this time!

Anything to declare?

I should probably give a quick sketch of my background before I finish as I am slightly biased -- most of my work has been in the telecommunications sector, where I either worked with a large code-base (legacy) or a large, distributed team (new development). In no way was I working in the XP style, although I became test-infected easily I found it difficult to even imagine how to apply some of the XP practices to my workplace.

XP changed the way I code and work, for the better, but in a large environment, with no contracting customer, and few experts on a complex domain involving simultaneous hardware development I couldn't see any way to do XP. I'm not saying what we did was good, I'll be the first to admit it was broken (hmm, and I'm unemployed now, time to go and think about cause and effect!). The key assumptions of pure XP just didn't fit the industry I've seen most of. (To be fair, McBreen would have called these projects "systems engineering" and placed them outside of the discussion.) Now that I'm seeking employment again, I'm a lot more aware of methodologies and am much keener to work within an Agile framework, as I believe that all of the methodologies, XP included, offer a much better way of developing software. However, the key point remains -- XP cannot be applied everywhere.

Lastly, I should make it clear that I received a review copy of this title from the publisher and did not pay for it. I paid for my own copy of Software Craftsmanship.

You can purchase Questioning Extreme Programming from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Re:sacrificial lamb

[dildatron]

hah! we 0\/\//\/ j0u! w3 ar3 s0 l33t th4t we typ3 4ll 0ur c0de |/\/ l33t sp33k 4nd tr4nsl4t3 |t int0 m4ch|/\/3 c0d3 0urs3lv3s w|th n- c0mpil3r!

Re:done it, didn't like it

[ekrout]

done it, didn't like it
Just like Clinton.

He got to you, too? And all along we thought he only fscked interns!

Re:As a developer, XP slows me down

[Coz]

At one job, we'd spend six hours working the bug fixes due for first shift (there weren't enough servers to go around, so we subs got to do shift work, too - I was on second - 12 hour days, 10 on the clock), fired up the Compile-From-Hell (Ada - sssllllooooowwww compiler, lots of code), and checked out, headed for the casinos (Mississippi Gulf Coast, the first had just gotten installed). Came back a couple of hours later (or on a page from the Puritan who volunteered to watch the builds scroll past) and started testing to finish out our shift.

Later on that same job, they sent us to the lead corp's site to do final integration (since their on-location management had screwed up, we all got drawn back to the mothership). We had to do the same stuff, but with more code - and even back at Home Base, they only gave us 2 servers for our builds, so they took hours. One night approaching midnight, the VP in charge of the project walks through - only 2 of us are there, both subs, and we're both playing Minesweeper! He asks what we're up to, looking pointedly at the game screens, and I pop up the build windows behind it (X on Windows) and show him the lines scrolling past, 1 every 45 seconds, and guestimate that we have another 45 minutes before the builds finish, but can't leave in case they break. He nods, we chat nicely for a bit... and three days later, we have 2 more build servers.

Re:sacrificial lamb

[an_mo]

If anything, this is another proof that /. moderation system doesn't work. A post/thread with an explanation of what XP is should have been on top of the moderation raknking but I have yet to find one message or link

Re:Only terrorists think of casual, non-vanilla se

[Boronx]

(BTW, Clinton was "[suboenaed] for having his dick sucked" by Paula Jones' attorneys, not by "Senior Republicans"). Only in the sense that the Jews were killed by SS squads and not Hitler or Eichman. (Whoops...Godwins law) The first part of your post is true. Prostitutes in cities that have hosted both, report triple the business at the Republican convention compared to the Dems.

Re:sacrificial lamb

[Killall -9 Bash]

It probably has something to do with snorting a few lines, running around on stage screaming like a WWF reject, then chanting arcane mind-control mantras before a crowd of thousands of professionals trapped in a satanic IT cult.

DEVELOPERS, DEVELOPERS, DEVELOPERS, DEVELOPERS........