Somone recently asked me what I thought of Gerold Keefer's assertion that XP is harmful. My response went something like this:
I don't care what he thinks (Obviously) and yet I realize that's not terribly interesting or enlightening...
So, I will also offer why I don't care:
Even if I grant that Gerold understands XP (and I do not), and that is article is well written (it is), he seems to have missed the point of what a process is for:
I don't set out to do XP in order to make my projects work, I set out to make my projects work, and I just happen to find XP helpful in doing that. If I didn't I wouldn't do it. Since I do, he's wrong. I don't care if he or someone else believes that to be false, because its just a simple statement of fact: I focus on making projects work, and I find XP helpful in doing so, therefore XP is not harmful -- at least for those of us who are succeeding and using it.
The point may not be obvious, so I will spell it out: We (the people working on software) succeed (or fail), not our process.
Many Anti-XP pundits have it reversed (I suspect Gerold is one of them): They view XP -- and indeed any process methodology -- as being held up as a way to make projects work, and that is backwards to how success really happens. On the statement: "Practice XP (or any methodology) and you will get reliable software", I concur that this is a really harmful idea -- but its not what we XP advocates are advocating.
In short, Gerold is non-agile in that he views process as having a larger impact on a project's success than its people, and so interprets XP on those grounds. He and others like him see nothing -- or very little -- in the XP process definition that will make people successfully deliver, and dismiss as dangerously irrelevant the notion that people can make a project succeed using XP (and even more importantly, with less pain and overhead than they could with a process that he may be more comfortable with).
You can usually tell by their language which of these views someone holds. You'll note in the paper that Gerold is not in-effect saying "I would make these mistakes" but rather "others may make these mistakes." In that I agree with him -- but its true of any process. He wants a process (his process of course) that will make others succeed. Agilists believe this view of process is inherently flawed. No process makes you successful, but people who will succeed anyway can do so with a more or less painful process. XP is simply the best collection of practices I have ever found that are generally useful in addressing the problems I try to solve on each project -- but in the end, I succeed because of me and the people around me, not our process, which we readily change in response to our current challenges.
This Agile viewpoint so fundamentally changes the role of process that it is easy to see XP advocates -- many of whom themselves have yet to realize this difference -- as advocating a silver bullet that will make your software reliable.
So let me state it again for Gerold (and everyone else): we don't claim XP will protect us from the harmful, we claim that it aids the successful. Since Gerold has that backwards, and has thus has missed our point entirely, I don't care what his paper claims about how others may use XP, I am going to continue successfully delivering software, and using XP to do so.
Posted by wcaputo at January 9, 2004 05:30 PMhello william,
given the fact that you don't care about what i think, it pleases me that
you dedicate 625 words to my article.
i would like to add that maybe you overlooked that i am in no way dismissing
the possibility that XP in some cases can help to achieve success. what i do
question is the applicability of XP to general/average development
situations.
best regards,
gerold
Yeah
I agree with William that agile is in place to help people come down to a
process that will let them succeed with the minimum of pain.
In this respect I find successful "Sports Teams" very similar to "Successful Agile Teams". They just do what is necessary to succeed. So in that essence, "if to succeed" , "XP helps me" then why not? But to say "XP will make you successful" will be wrong. XP is charming because its simple, it has a simple set of practices which are executable and "Thinking Heads" use these practices taking into account their context.
The point that is missed by Gerold is "XP or Agile is Simple in essence".
"Only for those who want to Succeed".
Cheers.
Ciao Chiara,
Interesting. Snip 'religious' argument Doesn't it say that to make projects work, the author finds that XP helps him do that. Furthermore, a project's success is much more dependent on the people and their interactions than on the particular process they use, or, to use your metaphor, getting to heaven is more about people interacting with each other in a heavenly manner than following a certain religion. I disfavor metaphors in technology but since you brought it up... Don't we all agree that People and their Interactions have a greater impact on a project's success and are therefore more important than the process? I think the author isn't interested in "converting" as much as "sharing" what helps him successfully complete a project. Why such an angry reaction?
TheGladio
Posted by: TheGladio at January 14, 2004 04:35 AMAny process would work as long as there are enough right skilled(including technical and project management) people work on the project.
Posted by: San Fran at January 14, 2004 12:16 PMUncle happy has become very famous for knowing how to tell a good horse from the others.
A lot of people come to visit him. At first it was the reporters, asking for his secrets. Then it was the rich and powerful, asking him to find good horses for them. When the backlog of his services is getting too long, he decided to start a boot camp to train a few students so that they would be able to help more customers. (As an after thought, he should have given seminars and written books.)
If you happen to know Uncle Happy, you would surely have loved him because he is smart, funny, and completely sincere. He poured his heart out and tried his very best to share his knowledge with his students.
The training, however, did not go very well. He tried one way after another, but nothing seemed to work. His insights about drive, determination, potential, etc., like the Chinese used to say, have gone in one ear and out the other. After much frustration, he finally comes up with a picture of what an excellent horse should look like, completed with highlights of the important features (was it 12?) such as big eyes, strong legs, streamlined bodies.
The students were very happy. Finally, at a long last, they got what they wanted, something they can put their hands on. Equipped with this wonderful picture and accompanying instructions, they set out to find the best horses immediately.
Do you know what did they find? Well, the first student came back with a
grasshopper. The second, a frog. But none of them come back with a horse that
was any good at all.
People not proceses? Uh oh....how are the six sigma folks gonna dealt with this?
The holy grail for managers is the perfect process where you just plug in resources that meet the minimum qualifications and poof! you get the desired output. Well, maybe with a few black belts riding herd.
How 'bout a six sigma team. "We can use whatever your process is and produce consistent six sigma output. We have our preferred processes but we can work with whatever you've got."
I'll take the team.
Posted by: Dan Sickles at January 20, 2004 08:37 PMActually, six sigma is an excellent vehicle for determining how well XP (and agile) fit in an environment. Driven by what the "customers" (business, developers, management) really need - Voice of the Customer in six sigma language - and gathering some baseline metrics, the organization can quantify their success.
What we found (at a very large financial institution) was significantly improved quality at much lower costs, and higher business / developer satisfaction. A very unusual win-win-win.
The "magic" wasn't six sigma ... it was XP / agile allowing the team to be more successful. XP was the enabler, six sigma provided proof to management of the success. As Bill wrote, developers "...set out to make ... projects work, and [they] just happen to find XP helpful in doing that."
Posted by: BJ - Black Belt at January 22, 2004 09:48 AMVery well said!
Posted by: Robert C. Martin at January 23, 2004 04:52 PM0. Without data, a 'this versus that' is NOT a debate, but a series of assertions. That's a religious war by definition - it cannot have a resolution.
Gerold's article does mention he's only found 3 studies of 'XP' effectiveness. Conversely, he does not mention any studies of convential Software Engineering practice showing it's effectiveness.
============================
1. Methodologies/ Processes do not work by themselves:
Proof: For all methodologies/process, there are projects that have succeeded & others have failed.
Corollary A. The same people can use a methodology on a successful project, then fail on their next project doing exactly the same things.
Corollary B. Some methodologies may be more consistent in delivering failures or successes.
============================
2. Scale is everything in I.T. projects -- Alan Kay, creator/writer of first
(?) O-O language, Smalltalk.
2A. Different Application areas require completely different skills and capabilities: Real-Time, Telecoms, GUI, Server, Embedded, Database, Commercial/Accounting, Web, text, ...
Discussing Methods without specifying the area of application and scale of project is meaningless.
============================
3. 'Quality' and output are linked.
More lines of code can be produced if the defect/fault/compliance contrainsts are relaxed.
Many types of systems like real-time, Operating Systems, hardware & device drivers, Telecoms - have very stringent defect requirements. Motorola came up with 'Six Sigma' in response to these 'defects per Million' requirements.
'Formal Methods' have come closest to providing the best Cost-Effectiveness in these highly defined and constrained application areas.
I.T. does not measure, nor has a vocabulary for, the level of defects and their severity/impact.
============================
4. 'Qualtiy' has multiple dimensions and no single definition.
One common dimension is 'execution' - both the absence of execution faults and precise or elegant craftsmanship. Lack of Defects is a 'hygine' condition, not a satisfier.
'Design' is another dimension of 'Quality'.
Great Designs are produced by the best practitioners.
Programs are intangible and ephemeral.
Assessing them is impossible for non-practitioners.
============================
5. Individual Capability of 'I.T. professionals' varies by at least 10-1000
fold.
Capability has two dimensions, defect-adjusted output and 'degree of difficulty'.
There are many disciplines and sports that routinely & consistently assign
'degreee of difficulty' measures to subjective performances.
Scores are given for 'execution' and 'artistic impression'.
Implication 1: No project/SE methodology I know tries to assess a) the degree of difficulty of each subproject/task and b) matches the performer to it.
Implication 2: University grades are the last time IT practitioners are graded/separated on their capability.
The old 'saw' says it all: Don't send a Boy to do a Man's job...
But when you can't separate the Men from the Boys, how do you know who to
send??
============================
4. I.T. is a _performance_ discipline like music, art, surgery, dentistry,
architecture...
Our 'Performances' are code - they can only be assessed by those who can view and understand the performance - high-capability practitioners.
============================
5. Methodologies and Open-Source:
O-S is very pragmatic and minimalist: Any methodologies, processes or tools that _work_ are used.
A. Tools & Methodologies:
Only those tools and processes found to be essential and productive are adopted
by successful O-S projects: Bug-tracking, version control, QA/testing process
and Config. Mgt.
Centralised Design and Project Mgt. are NOT used.
B. Productivity & Quality:
There is no evidence that either XP or S'ware Eng. methods used commericially
have higher output or quality than the successful Open Source projects.
This highlights the lack of metrics
============================
6. I.T. is still an Industry, not a Professional.
Professions learn from practice:
a) Failures are investigated & causes, prevention, remedies recorded and
promulgated, and
b) 'Best Practices' are quantified and recorded.
Proof by Example: There are no professional repositories of 'Lessons Learned' and quantifiable 'Best Practices'.
============================
7. Yet Another Productivity Revolution...
'Computing' is about 50 years old.
Over the last 30 years, every 5 years there has been a new 'Great White Hope'
produced with _substansiated_ claims of a ten-fold increase in productivity:
Unix, 4th-Gen tools, CASE, S'ware Eng, O-O, XP, Business ReEngineering, ....
Concominantly, until 2000, there was a perceived (massive) shortfall of 'programmers'. This has evaporated with the .COM bust.
============================
Summary:
The only long-term data on the success of I.T. projects, the [USA] Standish
Group's 'CHAOS' report, cities the 1994 project success rate as 16%, and the
2002 rate as 23%. No public comments on project scale or methodology are
available.
Real data allows Real argument. That's not available...
XP _could_ be great, or could just be a collection of useful, proven tools...
'Cowboys', those who hoop and holler and crash around blindly, NEVER see themselves as anything but highly skilled professionals.
Posted by: stevej - Australia at January 31, 2004 12:27 AM> Gerold's article does mention he's only found 3 studies of 'XP' effectiveness.
not correct: i am referencing at total of 5 studies, some of them are comparing SE practices to extreme programming practices.
> Conversely, he does not mention any studies of convential Software Engineering practice showing it's effectiveness.
again, one of the mentioned studies compares for example pair programming to "classical" reviews. the point of the paper was not to validate software engineering practices, but to point at extreme programming aspects that i consider to be harmful compared to SE approaches. however, there are numerous studies that indicate benefits for SE practices such as for example inspections. i certainly agree that a process "per se" is not a sufficient condition for the reliable development of software. it is, however, a necessary condition.
best regards,
gerold
Posted by: Gerold at February 3, 2004 06:42 AMI've read Gerold's paper with some attention. Here are my impressions.
[ A digression here. I work for a software company as a data architect. We are not an XP shop. I attend almost all XP user group meetings here in Toronto. I am curious about XP but not fanatical.]
Gerold was willing to take a serious look at XP since he had heard so much about it. His points of view are based on his experience. They may not apply to everyone. This fact is stated clearly in the paper.
The most interesting fact that he presented has not been contradicted by anyone here: The "XP-seminal" C3 project at Chrysler was cancelled! Is that interesting or what?
His point about simplicity is very well written. I agree completely with it.
I have never seen a project that was the simplest possible in the sense that Gerold means. Most people misunderstand the Business Requirements and come up with an unnecessarily complex solution that is technology heavy and weak on understanding the business. I believe that Kent Beck's admonition to keep it simple was probably intended to avoid this scenario. Unfortunately, most XP practitioners take it to mean "just do something that works."
The software industry has enough experience to know that that is a recipe for disaster. It works on small projects, not on large projects where the most energy is devoted to coordinating the efforts of various sub-teams.
In this context, Gerold's comments about simplicity are very valid and true.
XP has many good points, as Gerold points out in Section 3 of his paper. QA, Code review and Design review viewpoint, refactoring, courage and willingness to change, all these are XP's strengths. These are something that almost the whole software industry has accepted willingly. We do have XP to thank for that.
Is everything about XP good? I do not think so. How can XP practitioners
know that XP will work in all situations? They don't because XP is still
relatively new. So it behooves them to be more humble and less dogmatic. Once
XP has been shown to be the best, then they should start boasting and say " I
told you so." Until then it behooves them to be more humble and explain the
possible benefits without claiming it to be the next great thing.
This discussion reminds me about an old joke:
What's the difference between a methodologist and a terrorist? One can negotiate with a terrorist.
:)
Posted by: Rune Toalango Johannesen at April 2, 2004 10:30 AM