"XP Programming" Myth Debunked (long)
Andrew Rybenkov
Matt Stephens, Doug Rosenberg "Extreme Programming Refactored: The Case Against XP", Apress 2003
- quite interesting book, - if you have some spare bucks (and have interest into XP) - get it.
Here some excerpts:
----------------------------------------
back cover:
The book is meant to provide an independent look at Extreme Programming. It is meant to cut through the marketing hype
of Extreme Programming and expose a number of weaknesses with this approach to software development. It tries to draw a
distinction between true "agility" in a software process and "fragility" inherent in techniques such as oral
documentation. Extreme Programming (XP) is a consummate mix of good goals, some good advice, and lots of bad advice. The
goals and the good advice draw people in; the bad advice can potentially cause projects to fail. The XPers' theory is
that when applied together, this mixture of rules will somehow magically be safe. XP therefore represents a high-risk
process, wrapped in a "feel-good" methodology. The marketing, hype, and earnest self-assurance of its authors will
convince many project leaders to try out XP on their next project.
----------------------------------------
Chapter 14 Scalability
14.1 Painting Over the Cracks: XP on a 50-Person Project
What really happens when XP scales up to large projects? In this section we analyze a case study of a 50-person XP
project (with the team referred to as ATLAS). The case study can be found online here:
http://www.xpuniverse.com/2001/pdfs/EP202.pdf.
The ATLAS project was conducted by ThoughtWorks, Inc., an XP “shop” and home of Extremo author Martin Fowler. In this
project, we see the circle of snakes really come to life.
Note that when Matt wrote the original “The Case Against Extreme Programming” article
http://www.softwarereality.com/ExtremeProgramming.jsp and introduced the circle of snakes a few years ago, he had not
seen this research. But, as you’ll see, XP breaks down in just about all the ways you would expect it to as projects
grow in size. In fact, some of the breakdowns would occur even on smaller projects.
The first thing to note about this particular study is that, after a year and a half of XP, the “code is definitely
worse than [when they] started.” Yet this is one of XP’s biggest selling points: that repeated refactoring supposedly
results in greater code quality. So, what went wrong?
Looking at the case study, it’s quite obvious to us that the circle of snakes broke loose. One practice slipped, meaning
that the next in line stopped working, and so on. The team, meanwhile, saw this as a sign that it needed to work harder
at applying the XP practices. (In the words of Boxer the cart horse from George Orwell’s Animal Farm, “The only possible
answer is that I was not working hard enough. I will work harder!” Or, to put it another way, “The only possible answer
is that I was not refactoring hard enough. I will refactor harder!”)
XP is simply an impractical approach to follow on medium- to large-scale projects. Even a medium-sized, 50-person
project like the one described in the case study quickly shows XP’s shortcomings. To apply XP’s practices effectively
involves tailoring it, resulting in something that the team might prefer to call XP, but really isn’t.
----------------------------------------
Chapter 2: Where Did XP Come From? (Chrysler Knows It Ain’t Easy . . .)
2.1 Overview of C3
C3, or Chrysler Comprehensive Compensation, was the XP “poster-child” project. Many of the claims about XP working on
larger projects were based on the reputed success of the C3 project. In fact, many of the people (Kent Beck, Ron
Jeffries, Martin Fowler, Chet Hendrickson, Don Wells) who wrote the XP books available on the market today worked on C3.
Most of the initial 2 years’ worth of hype about XP came from the purported “success” of C3. Quite naturally,
programmers who had no interest in doing design or documenting their work began jumping on the bandwagon. After that, XP
books started coming out by the dozen, and the whole thing gained an aura of respectability.
To claim C3 as a success when it was a failed payroll replacement project that got cancelled after 4 years is, we feel,
a total distortion of the truth. However, if you repeat often enough that a failed project was really a success, and you
say it with enough conviction and gusto, over and over again (the marketing term for this is proof by repeated
assertion, as in “Cigarettes don’t cause cancer”), then people will of course start to believe you.
If you look on the C2 Wiki’s Cthree Project Terminated page ( http://c2.com/cgi/wiki?CthreeProjectTerminated), you can
find a very interesting discussion about this project and the impression it left on the folks at Chrysler. The Chrysler
Comprehensive Compensation page ( http://c2.com/cgi/wiki?ChryslerComprehensiveCompensation) is also interesting.
Everybody should read these pages!
----------------------------------------
--
Andrew Rybenkov.
Liz
> I dont think there is any new news here, every experienced developer
> knows there is no magic bullet to development methodologies. Just
> learn as much as possible and implement what you think is right for
> your company.
And of course that "right" varies with the team and project :)
Lauchlan M
> > Case Against XP", Apress 2003 - quite interesting book, - if you have
> > some spare bucks (and have interest into XP) - get it.
>
> knows there is no magic bullet to development methodologies. Just learn
> as much as possible and implement what you think is right for your
> company.
Yep.
I thought XP was meant to be more suited to smaller companies/projects, and
that other methodologies (e.g. feature driven development) were meant to be
more suited to medium-large projects and companies.
So, in that light, it is hardly surprising that the case example given in
the book for XP, involving >= 50 developers, presents some problems.
My 2c.
Lauchlan M
Craig
> Case Against XP", Apress 2003 - quite interesting book, - if you have
> some spare bucks (and have interest into XP) - get it.
I dont think there is any new news here, every experienced developer
knows there is no magic bullet to development methodologies. Just learn
as much as possible and implement what you think is right for your
company.
Craig.
Alisdair Meredith [TeamB]
> I dont think there is any new news here, every experienced developer
> knows there is no magic bullet to development methodologies. Just
> learn as much as possible and implement what you think is right for
> your company.
I wish I could remember who I am quoting from an ACCU conference a
couple of years back.
Two important features of software development:
i/ The bad news: There are no silver bullets
ii/ The really bad news: However, there *are* werewolves!
AlisdairM(TeamB)
Jim Cooper
> I dont think there is any new news here, every experienced developer
> knows there is no magic bullet to development methodologies.
Indeed, Fred Brooks wrote about it more than a quarter of a century ago.
> Just learn as much as possible and implement what you think is right for your
> company.
I agree. I've used some of the XP techniques like pair programming to
great effect. However, I didn't use the whole XP thing, and I wouldn't
recommend pair programming for all tasks either.
Refactoring and unit tests are other useful techniques not unique to XP
that definitely have a place outside it.
Cheers,
Jim Cooper
_______________________________________________
Jim Cooper j...@falafelsoft.com
Falafel Software http://www.falafelsoft.com
_______________________________________________
Michael Anonymous
> C3, or Chrysler Comprehensive Compensation, was the XP “poster-child” project. Many of the claims about XP working on
> larger projects were based on the reputed success of the C3 project.
I'm not sure if everyone knows the following facts,
so I'll contribute them:
The original C3 project began in January 1995.
Kent Beck ( author of eXtreme Programming )
helped on this project in 1996.
Chrysler was taken over by Daimler-Benz in 1998.
Basically, when Chrysler was taken over by Daimler-Benz everything went
to hell for Chrysler.
"
Fortunately for Toyota, Chrysler was bought by Daimler. Chrysler's
renaissance proved to be just another flash-in-the-pan threat that would
vanish as quickly as it appeared; by 2000, the company was again on the
verge of bankruptcy and scrambling to simply break even. What happened?
"
"
By gutting the leadership of Chrysler, Daimler gutted the culture that
Chrysler was proudly building-a culture that made companies like Toyota
nervous. Instead of building on this proud culture and protecting it,
Daimler tore it clown through radical cost-cutting, eviscerating
Chrysler's strengths.
"
Source:
http://www.aiada.org/article.asp?id=31774
The original C3 project began in January 1995.
http://members.cox.net/cobbler/XPDangers.htm
Chrysler was bought by Germany's Daimler-Benz in 1998.
Kent Beck ( author of eXtreme Programming ) helped on
this project in 1996.
http://www.cbsnews.com/stories/2001/03/19/national/main280012.shtml
Peter Gummer
> Extreme Programming Refactored
And here is the debunking of the debunking:
http://www.xprogramming.com/xpmag/books20030904.htm
"This book is painful to read for anyone who understands what XP is,
because it goes to such pains not to understand, to take out of
context, and to distort.
It is dangerous to read for anyone who does not understand what XP is,
because it goes to such pains not to understand, to take out of
context, and to distort."
It's written by Ron Jeffries, one of the most conspicuous proponents of
XP.
- Peter Gummer
Andrew Rybenkov
> because it goes to such pains not to understand, to take out of
> context, and to distort.
> XP.
Ha-ha, rather natural reaction for a man that was caught with his pants down ;)
(*
Btw, Rudy, (and other aphorisms fans) catch it:
"“I think maybe concentration is the enemy. Seriously. If you’re working on something that is so complex that you
actually need to concentrate, there’s too much chance that it’s too hard.”
(Ron Jeffries, posting to the C2 Wiki page “Pair Programming Ergonomics,”
http://c2.com/cgi-bin/wiki?PairProgrammingErgonomics)
*)
Mr Jeffries, probably, was not happy with the next part (of many)
---------------------------
Pair programming, like many of the other XP practices, appears different in theory and practice. Pair programming as a
voluntary activity should be encouraged, when appropriate.
It’s important, however, to not lose sight of the fact that programmers need peace, quiet, and space in which to think
and concentrate, despite Ron Jeffries’ claim to the contrary. The social aspects of pair programming can be very
difficult. And, when you add it all up, you’re still taking two programmers to produce what a single programmer would
under normal circumstances.
---------------------------
--
Andrew Rybenkov.
Andrew Rybenkov
> so I'll contribute them:
here is another exerpts (abridged by me to keep it short more or less,
(referenced below figures are snapshots of webpages, I added corresponding links in square brackets)
---------------------------
XP is announced to the world with a flourish, with grandiose claims such as “The Best Team in the World,” as we see in
Figure 2-2.
[www.computer.org/SEweb/Dynabook/DaimlerChryslerSdb.htm]
Semiannual project C3 began in January 1995 as a fixed-price contract. The majority of the project was finished by early
1996, but it consisted mostly of a lot of GUI screens and some functions that were calculating peoples’ taxes wrongly.
In March 1996, the C3 project was floundering. So Chrysler brought in Kent Beck, who in turn brought in Ron Jeffries,
who in turn brought in his crack team of XPers (except then, of course, they weren’t known as “XPers”).
Beck’s plan was to courageously throw everything away and start again.
As with many doomed software projects, C3 (having been relaunched with its new Extremo power team) started out with high
hopes and enthusiasm. And they were courageously “Doin’ the Simplest Thing That Could Possibly Work”!
The team was busy shaping the XP practices and doing the simplest thing possible to get today’s piece of work done (see
Figure 2-3). [www.xprogramming.com/publications/dc9810cs.pdf]
Was the C3 payroll really more complex than other payroll systems? C3 was being powered along by XP and a team that
called itself “the best software development team on the face of the earth,” shouting “BDUF!” and “YAGNI!” at each
other, yet after 4 years C3 was only one-third complete.
Ron Jeffries wrote (on January 4, 2002):
“It paid somewhere just under 10,000 [employees]. It was hoped that it would pay all Chrysler employees, somewhere
around 100,000. "
---------------------------
with such 4-year progress the project was canceled at Feb, 1st, 2000. Personally I would not blame Daimler for it.
And finally another excerpt
---------------------------
if you look on the C2 Wiki Web (read it yourself at http://c2.com/cgi/wiki?CthreeProjectTerminated), you’ll find this
quote (referring to Frank Gerhardt from Chrysler speaking at the XP 2000 conference):
“If I remember correctly Frank said words to the effect that, at DaimlerChrysler these days the terms: ‘C3’,
‘ExtremeProgramming’ and especially ‘PlanningGame’, and to some extent ‘SmallTalk’, ‘GemStone’ and ‘object-oriented’ are
now unutterable by anyone wishing management there to take them seriously. He got a rather nervous sounding chuckle from
the audience with the line ‘Chrysler has done XP OnceAndOnlyOnce’.”
---------------------------
--
Andrew Rybenkov.