- Shopping Bag ( 0 items )
Extreme Programming Refactored: The Case Against XP (featuring Songs of the Extremos) takes a satirical look at the increasingly-hyped extreme programming (XP)methodology. It explores some quite astonishing Extremo quotes that have typified the XP approach quotes such as, ?XPers are not afraid of oral documentation,? ?Schedule is the customer's problem,? ?Dependencies between requirements are more a matter of fear than reality? and ?Concentration is the enemy.?
In between the ...
Extreme Programming Refactored: The Case Against XP (featuring Songs of the Extremos) takes a satirical look at the increasingly-hyped extreme programming (XP)methodology. It explores some quite astonishing Extremo quotes that have typified the XP approach quotes such as, “XPers are not afraid of oral documentation,” “Schedule is the customer's problem,” “Dependencies between requirements are more a matter of fear than reality” and “Concentration is the enemy.”
In between the chuckles, though, there is a serious analysis of XP's many flaws. The authors also examine C3, the first XP project, whose team (most of whom went on to get XP book deals shortly before C3's cancellation) described themselves as "the best team on the face of the Earth." (In a later chapter, the authors also note that one problem which can affect pair programmers is overconfidence—or is that "eXcessive courage"?). The authors examine whether the problems that led to C3's “inexplicable” cancellation could also afflict present-day XP projects.
In the final chapter, Refactoring XP, Matt and Doug suggest some ways of achieving the agile goals of XP using some XP practices (used in moderation) combined with other, less risk-laden methods.
|Emperor's New Code (a Story)|
|About the Authors|
|Pt. I||Another Fine Mess You've Gotten Me Into (Laurel and Hardy Take Up Programming)||1|
|Ch. 1||XP in a Nuthouse (Oops, We Mean Nutshell)||3|
|Ch. 2||Where Did XP Come From? (Chrysler Knows It Ain't Easy ...)||31|
|Ch. 3||The Case Against XP||57|
|Pt. II||Social Aspects of XP (Mama Don't Let Your Coders Grow Up to Be Cowboys)||83|
|Ch. 4||Extremo Culture||85|
|Ch. 5||The On-site Customer||117|
|Ch. 6||Pair Programming (Dear Uncle Joe, My Pair Programmer Has Halitosis)||135|
|Ch. 7||Oral Documentation (Oxymoronic, or Just Plain Moronic?)||161|
|Pt. III||We Don't Write Permanent Specs and Barely Do Any Upfront Design, So ...||181|
|Ch. 8||Design After First Testing||183|
|Ch. 9||Constant Refactoring After Programming (If It Ain't Broke, Fix It Anyway)||201|
|Ch. 10||User Stories and Acceptance Tests||227|
|Pt. IV||The Perpetual Coding Machine||247|
|Ch. 11||Software Is Never Done (The Schedule Does Not Exist Per Se)||249|
|Ch. 12||Emergent Architecture and Design||269|
|Ch. 13||Embracing Change (Emrace People, Manage Change)||293|
|Pt. V||The Big Picture||311|
|Ch. 15||Refactoring XP||337|
|Ch. 16||Conclusion: Neutralizing the Reality Distortion Field||371|
Posted May 23, 2005
Stephens and Rosenberg incisively deconstruct XP. In cutting prose, they explain why XP has serious problems in any practical implementation. They highlight the first serious use of XP, in Chrysler. Which ended in the project's cancellation after 4 years of effort. But somehow, the XP proponents tried to sweep that under the rug. The book explains why XP is so brittle. For it to work in a large project, all its aspects need to be implemented. If just one is not, then it endangers the entire operation. Pair programming and collective ownership of code is shown to be deeply flawed. Any group of programmers is likely to have members varying widely in ability. Programming is an elitist field. Talent matters in any complex project. But those aspects of XP invariably invite programmers to tinker with and degrade code that was written by better programmers. Who then have to repair the damage. The aspects do favour a weak programmer, because her bugs get fixed by others. But a real danger to the project is that your best people leave in disgust. The authors discuss this and other topics in very readable detail. Hopefully, they will disabuse you of any illusions about XP.Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.
Posted September 9, 2003
I liked this book, because it dares to point out the dangers in having blind faith in XP, something that seems to be a requisite in order to be truly doing XP. It is not totally against XP, detailing some of the areas in which the author thinks XP has something to add to software engineering, but helps uncover the many bizarre, contradictory, or simply untrue statements made in the XP world. In fact it is quite easy to see that with this book in hand you have a cynical, wise cracking guide, that can actually make your XP projects safer and less prone to extremes, so to speak. It does all this with lashings of humour. If you don't like humour in a computer book, go elsewhere. If you love XP and believe all unbelievers are scared, in denial, blind, then you won't like the humour either. If, like Ron Jeffries, a lot of the book is about you, you most certainly won't like the book. I'm quoted in the book myself, so can't claim to be a neutral observer. But there again, no one really is, we all have a viewpoint, and it colours all we do and say. If you do XP or are thinking of doing XP, buy this book. It is an antidote to all the hype and rah rah found in the many many XP books out there. Already there has been talk about how to 'stop this book'. Enough said. There's a sample chapter 6 available. http://www.apress.com/ApressCorporate/supplement/1/150 /1 590590961-1185.pdf This more than anything will help you decide if this book is for you.Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.
Posted September 3, 2003
Bear in mind that this reviewer is an Extreme Programming proponent and author. That said, I firmly believe that reasoned consideration of the strengths and weaknesses of the XP process is appropriate. Unfortunately, this book does not meet that simple criterion. I would recommend that the interested reader consider instead McBreen's 'Questioning Extreme Programming', or Boehm and Turner's 'Balancing Agility and Discipline'. A more complete review of this book, and the above two, is available on my web site, www.XProgramming.comWas this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.