Talk:Extreme programming/Archive 1

Linking an editor-written webpage

I've written a whitepaper at http://www.lux-seattle.com/resources/whitepapers/waterfall.htm that I think is worthy of an external link from this article, but I don't think it's appropriate for me to link it from the article myself. Could someone else take a look & link if you feel it's appropriate? Or maybe from another related article? -- Jmabel 20:00, 26 Jan 2004 (UTC)

Extreme programming and outsourcing

Would anyone care to describe the relationship between extreme programming and outsourcing (if any)?

168.209.98.35 02:33, 29 Feb 2004 (UTC)

Extreme programming relies on getting everyone in a room together for JAD sessions. There shouldn't be much issue as to whether everyone is legally employed by the same organization -- the method works just as well (or as badly) with contractors, as long as they are pretty much dedicated to the project -- but it certainly works best when developers and users can have frequent face-to-face contact. Some of these techniques are still useful even in an "offshore" outsourcing situation, but the "extreme programming" paradigm as a whole would be very hard to maintain. -- Jmabel 06:52, 29 Feb 2004 (UTC)

[2 YEARS LATER] The one project I did that was closest to extreme programming (we did everything on the list except we only pair coded 20 to 25% of the time), was an outsourced project, with the customers in Ohio and us in St Louis. In this case we used a combo of heavy use of Instant Messenging + Emails + Phone Calls + our company's IT director acted as a puedo-customer. (Our company was small, so lots of people had inflated job titles.) Joncnunn 19:46, 12 April 2006 (UTC)

Too many references

Sheesh, do you think we have enough references? I am removing all the references except for two. (How in the world did Mythical Man-Month get in this list?) If someone feels passionately enough to add some of these references back into the article, please limit it to a total of five. --Rookkey 04:31, 22 Aug 2004 (UTC)

What do we gain by removing what looks to have been a pretty good bibliography? -- Jmabel 04:47, Aug 22, 2004 (UTC)

The majority of the references dealt with how to implement extreme programming techniques in very specific environments (Java, C#, .NET, etc.). Even worse, many of the books in the list discussed Agile Programming, which is not XP. XP is a subset of Agile Development, not the other way around. The best reason for reducing the size of the list is to make it obvious which books are considered the authoritive tomes in the field. With thrity or fourty references, a casual reader has no idea which books are considered by experts to be the cream of crop and which are best skipped. I vote for keeping the reference list to a reasonable level of five entries. --Rookkey 06:50, 22 Aug 2004 (UTC)

I don't have a problem with saying this article isn't the place for the material (of which, BTW, I am not the author), but it seems more appropriate with things like this to try to find somewhere appropriate to refactor them to than to just delete them. -- Jmabel 18:26, Aug 22, 2004 (UTC)

Topics from 2005

Cleanup

Needs something doing about the images (you could just coment those sections out). Needs some areas translated into non techspeak and probably needs some NPOVing.Geni 10:44, 24 November 2005 (UTC)

Simplicity! There are too many words to describe this simple philosophy. Most of it has been explained already under the Agile article.

//TODO: Refactor the simplicity link that leads nowhere but to the XP simplicity core value (very wrong)

POV problems

Boosterism

I think some of User:129.33.49.251's recent edits are good, but others amount to boosterism. But, frankly, I've had enough of making any major edits on this page myself. Those who may want my own thoughts on the subject can find them elsewhere. I suggest that someone else review the recent changes. -- Jmabel | Talk 06:25, Apr 8, 2005 (UTC)

User:Wgiezeman, a new user, recently made massive changes. Most of what he wrote is not in Wikipedia style, including a lot of use of second person, a different approach to bullet points; it's also a bit boosterish.

This is a very unusual contribution from a new participant. I have to asked on his talk page whether he/she can you assure us that this is his/her own material, and not a copyright violation. I would also like to see sources cited: this is a pretty massive amount of material (especially the elaborate diagrams) to add without citations. -- Jmabel | Talk 07:10, Apr 27, 2005 (UTC)

User:Wgiezeman, thats me, i'm a student at the university of utrecht and this entry was part an assignment for a course about method engineering. My references are mainly from the Kent Beck books:

Kent Beck: Extreme programming explained: Embrace change, Addison-Wesley, ISBN 0201616416 Kent Beck and Martin Fowler: Planning Extreme Programming, Addison-Wesley, ISBN 0201710919 Kent Beck: Extreme programming explained: Embrace change, Second Edition, Addison-Wesley, ISBN 0321278658

The first two pictures about cost of change are placed with agreement of the original copyright holder. The other pictures did I make myself.

I must agree on you about the writing in second person, this should be edited.

• Could you please take first shot at the rewrite (and add the citations, per Wikipedia:Cite sources? I don't have a lot of time for this these days, or I'd do it myself. And do the Image pages make the copyright status of each image clear? Let me know when you think you have this all in order, so I can re-check at that point. Thanks in advance. -- Jmabel | Talk 15:57, Apr 27, 2005 (UTC)
• Well, since he didn't, I did. It could probably use more copy editing. Parts of the article are also, in my view very boosterish. The claim "It used to be thought that Extreme Programming could only work in small teams of under 12 persons. However, XP has been used successfully on teams of over a hundred developers. It's not that XP doesn't scale, just that few people have tried to scale it, and XPers refuse to speculate on this facet of the process," is entirely without citation. The criticisms are relegated to a tiny section at the bottom, and are not fleshed out at all. Here is an article critical of XP and similar approaches but not entirely dismissive of it. I wrote it (on contract to Lux). Does anyone object to my mining it for some arguments? -- Jmabel | Talk 04:51, Apr 30, 2005 (UTC)

(jgraley) I fleshed out the criticisms a bit, but I agree that the section with the flowcharts is going into an extraordinary amount of detail compared to the tiny amount of attention given over to the controversies. Software development techniques are not hard science, they are more like philosophies or political theories, and the conttradicting views and resulting debates are equally essential to an encyclopeadia article IMO.

I think the diagrams should go on the contributor's own site, which should be listed as a reference (assuming the XP cognecenti agrees with them).

• I think it's fine to have the massive diagrams here: it's probably perfectly OK that this ends up being a good primer on XP. However, I remain concerned with what seems to be a booster-ish tone. I think we could get some balance either by moving the existing "Controversial aspects" section much nearer the top, before we get into such a detailed description or by adding some mention of controversy either in the lead or the history section. As it is, most readers who are not specifically trying to actually learn the methodology will have tuned out long before they encounter any mention of controversy and criticism. -- Jmabel | Talk July 3, 2005 06:47 (UTC)

One-sided uncritical article

//TODO: Get back here in a few days and explain it, from a talented team experience. —Preceding unsigned comment added by 84.97.247.194 (talk) 06:15, 12 January 2008 (UTC)

This article badly needs a dose of reality. It was apparently written by uncritical devotees, and so it included all the tenets without any serious questioning of their facts. It is riddled with erroneous assumptions, straw men, and error.

This is particularly tragic for extreme programming because so much of their hot air comes from making unsupported caricatures of other practices while ignoring huge flaws in their own stuff that these extremists want to shove down everyone's throat creating more useless work than they could ever demonstrate having eliminated.

I do not say that all advocated XP practices are poor. There are some good ones mixed in if applied reasonably, but certainly none are invented there as good developers will attest and reasonabe application doesn't seem to be part of their religion as they practice their caricature-based denunciations.

a) Limited design phase: The idea, for example, that artificially limiting predictive design process makes you more flexible to future change is imply false.

b) Simple design: The idea that the simplest solution results by limiting design activities goes against years of experience. Simple designs, although certainly the most attractive, are often the hardest to discover, given the complexity of real requirements. The most horrific designs result from years of incremental hacks making a bad thing worse and worse.

c) Refactoring: The idea that incremental refactoring is the best way to get to the best model is unsupported in many cases if not all non-trivial ones. The sort of real refactoring that changes the established data model even in a tiny way is painful and seldom done after the first iteration, and anything else is mostly irrelevant.

d) The role of test cases: Doing it without a description of how the code should behave is dangerous. Test cases are only a significant safety net when your code always breaks in exactly the same places, not in new places as you implement different underlying algorithms, etc. since test cases can only be put in the right places by knowing how the code works, but the methodology says the test cases should be written before the code.

The idea that comprehensive tests should or can be written before coding but design descriptions should be neglected is simply ludicrous.

A simple design statement can capture an infinite set of cases whereas a test case can never capture them (except in trivial finite programs that could be replaced by a lookup table containing the inverse of the test cases).

We could go on and on.

And XP participation in Agile programming discredits Agile programming since their methodology so obviously makes code less agile and Agile credibility drowns in their false economy.

—The preceding unsigned comment was added by 166.70.15.233 (talk • contribs) 4 Sept 2005.

The points mentioned above are worth discussing although for the positions held they are not elaborated enough. It is not easy to really see what 166.70.15.233 means. For example s/he says that a simple design statement outweights an infinite set of test cases. Hirzel 10:52, 8 November 2005 (UTC)

• I basically concur, except perhaps with the last paragraph: there is no question that XP was a major influence on the "Agile" concept, and that Agile methodologies are worthy of consideration. Are you interested in taking this on? I certainly think it should be done, but I've already put more effort into just cleaning up the spelling and grammar in this article than I think it's worth. My own thoughts on the topic can be found at [1]: it's unsigned, but I wrote it. -- Jmabel | Talk 22:14, September 5, 2005 (UTC)

• I'd welcome a more detailed section on the controversy about XP, but I disagree with the notion that the article needs criticisms woven into it point by point. Whether and how XP works is a great question, but it's a separate question from how XP is defined. -- William Pietri 20:03, 7 October 2005 (UTC)

The real problem is that XP has hijacked the concept of test driven development. Being told you don't need planning and documentation is just a theory based on telling programmers what they want to hear. Pair development, little cards and whatnot is telling management what they want to hear, namely that programmers need WAY more intrisive oversight and micromanagement.

--Samiam95124 01:00, 8 November 2005 (UTC)

My experience of XP is pretty different than that, Samiam. On XP teams I feel much less intruded upon, and the planning processes have worked very well for me. Having done several XP projects, I feel it's more than just a theory. You can see an article I wrote for more on how we worked on one project. If you're ever up in San Francisco and want to talk about this over a beer, drop me a line. --William Pietri 02:11, 8 November 2005 (UTC)

Thank you for the link to your article, William. Especially the photos are nice and give a good idea how the process is put to practice. The above mentioned points could be a helpful guide line for things to adress more thoroughly in the article. Hirzel 10:52, 8 November 2005 (UTC)

Anti-pattern

does anyone know a term (I can't remember it) that refers to something in programming that is counterproductive or indicative of systemic problems? (Not sure if that's even the best description.) I thought it was an anti-paradigm but theres no sign of that anywhere. I know it had its own page on wikipedia. If anyone knows, could you email me at antiantitrust at mail.com? Thanks a bunch. 149.68.16.90 14:46, 11 Mar 2005 (UTC)

Probably "anti-pattern". -- Jmabel | Talk 22:38, Mar 11, 2005 (UTC)

Thanks a bunch, that is indeed the one. -Paul

Yeah, everyone knows about it but you got on the wrong article dude. There is obviously an article about it already. If not, learn about it and do it! —Preceding unsigned comment added by 84.97.247.194 (talk) 06:08, 12 January 2008 (UTC)

Ward Cunninham XP site link broken

Link to Ward Cunningham's Extreme Programming site broken. Shermozle 17:33, Mar 7, 2005 (UTC)

Copy editing

First Paragraph should state what XP is trying to achieve

i don't have a damn clue what this page is talking about. The page needs a serious explaination of what XP is for someone that does _not_ know what it is. --168.150.235.9 09:14, 21 November 2005 (UTC)

Right no i miss something like "XP tries to improve the development process of programming..." in the first paragraph. But since i a neither an expert in XP nor an native speaker i leave that to someone else.

Pictures

Ummm - Whats happened to all the pictures? (Somebody who's watching this page and knows what its about may get the message) Copyright? Lochok 11:06, 12 November 2005 (UTC)

Good question. Here's the deletion log from one of them. It looks like it wasn't clear who owned them, so after a couple of months of warning, they were nixed. Perhaps you could track down the original source and try to get explicit permission? --William Pietri 17:16, 12 November 2005 (UTC)

Oh, dear. User:Wgiezeman, from the University of Utrecht, was pretty clear on this above: "The first two pictures about cost of change are placed with agreement of the original copyright holder [meaning Kent Beck]. The other pictures did I make myself." -- Jmabel | Talk 02:30, 13 November 2005 (UTC)

That's no good. I imagine there's a way to get them back but I don't know how. Perhaps you could try #wikipedia? --William Pietri 11:44, 13 November 2005 (UTC)

& unfortunately, all versions of this page on the Internet Archive predate the relevant additions. But they often lag by as much as a year in posting material they've got. I wouldn't be surprised if these reappeared there. Or someone could go look at some of our mirrors... -- Jmabel | Talk 20:19, 13 November 2005 (UTC)

note: typo in image http://upload.wikimedia.org/wikipedia/en/7/7c/Com_rp3.gif: "devide in piles" --168.150.235.9 09:14, 21 November 2005 (UTC)

History

Added a large history section, something I felt any topic of this size ought to have. Sorry for not bringing it up here first. Context, origins, current state, future directions. I decided to put it as the first section; does anyone object? Refactor it downward. --AllanBz 00:59, 4 Jun 2005 (UTC)

I edited the History section and subsections a little bit. I'm just recording my reasons for making the changes I did.

History: I modified the introductory paragraph to give a concise timeline of XP from inception to present. I removed the bullet point list describing XP, as it looked like it belonged in a section describing XP proper; I'll put it back soon. I added the claim that "Extreme Programming reached the peak of its popularity in January 2002" based on comp.software.extreme-programming, and am willing to discuss with those who disagree.

Context: I changed "panacea" to "silver bullet" due to the very famous software engineering paper No Silver Bullet. It seemed to me more appropriate, considering XP is a software engineering methodology.

Origins: I did not modify the copy in the first paragraph of this section, but strongly disagree with the claims made here. Specifically the claim that C3 was an object-oriented development research project, as opposed to a software development project intended to deliver a working payroll system. I intend to modify this section, but need to spend more time researching before I'm willing to commit any text. Aside from this, I removed the external link to C3 project; I'll put it back in the References section.

Current state and Future directions: I didn't modify anything in this section, but do intend to massage the text when I get a chance.

Now to replace all the stuff I promised to replace. :-) /* Pradeep Arya 17:25, 2 January 2006 (UTC) */

Thanks for the work, Pradeep. I'll take a look at it soon. One quick comment: I think that XP is likely more popular than ever, at least in terms of people doing it. The reduction in message traffic is partly because communication has moved elsewhere, but mainly because a lot of traffic is a function of people learning about XP for the first time. Now most people have heard of it, reducing the long, contentious threads. Also, a lot of practitioners use the term "agile" more, even though they end up doing something pretty much like XP, because it's more palatable to execs. Certainly the main US XP conference, Agile 2005, was much bigger in headcount than the 2002 conference. -- William Pietri 08:54, 3 January 2006 (UTC)

I looked for other Extreme Programming related newsgroups via Google Groups, but it was the only one I could find. So I'm not so sure XP traffic went elsewhere, so much as simply decreased. I wouldn't be surprised if XP practitioners had moved to other "agile" methods (especially with Microsoft endorsing Scrum); but I would contend this is a decrease in the popularity of XP-proper, even if the other methods are similar to XP.

As for the increased headcount at XP conferences, I would contend this is more an indication that those who are already doing XP are becoming more involved with XP, rather than an indication that XP is gaining in popularity. That is, XP captures the attention of the software engineering field and sees an flurry of activity peaking in Jan 2002. After this point, people begin leaving XP, but those who choose to stay start getting more involved with XP (attending conferences and the like).

All that said, I will admit to two things. One, using the traffic on a newsgroup is a questionable method for determining popularity. Assuming somebody was willing to conduct a scientifically accurate survey, I wouldn't be willing to bet $100 on the outcome. In this sense, perhaps my claim isn't verifiable and ought to be removed. Two, I, personally, have an Anti-XP bias. I admit this because I am relying on neutrals and Pro-XPs to help offset any anti-XP bias my writing may introduce. I sincerely appreciate you taking the time to discuss my peak popularity claim, because I really am striving for NPOV. If you think the claim is "reaching" due to lack of evidence, I wouldn't be upset if you removed it.

Thank you! /* Pradeep Arya 20:30, 3 January 2006 (UTC) */

Looking into this further, what I mainly see is a migration of traffic off of Usenet and into extremeprogramming@yahoogroups.com and a variety of other mailing lists focused on specific subtopics like test-driven development or agile planning. The consensus among the list participants, though, is that traffic is a much better metric of controversy than of adoption. A similar consensus exists that it's still growing in terms of user base, although I couldn't find good numbers on either conference attendence or actual adoption. The best I can do is pull the group membership numbers for that main mailing list: in 2003 the group had 3223 members, and it now has 7647, suggesting that interest and participation have continued to grow vigorously. Given that, I'm going to do as you suggested and remove that statement. Thanks, --William Pietri 23:01, 13 January 2006 (UTC)

Peer review requested for waterfall model

Hi, I've just requested peer review for waterfall model. I'd really appreciate if some people could review the changes I've made. Thanks.  :) GeorgeBills 15:03, 17 November 2005 (UTC)

Article length

Hi! This article strikes me as way too long. There are many good external sites and books where people can get plenty of detail, so I'd like to pare this back to something easily read. My rough target would be something perhaps half this size, and perhaps less. Before I come up with a detailed plan, are there particular areas that people are especially eager to preserve or remove? Thanks! --William Pietri 07:40, 3 November 2005 (UTC)

I split the largest part of the article (Practices) out to another article Extreme Programming Practices. Thus one article that was unmanageably long becomes two large but manageable articles. Anybody that interested in Extreme Programming to that level of detail can be bothered to click a link to see it. /* Pradeep Arya 20:24, 2 January 2006 (UTC) */

You might consider what can be done with summary sections, etc., rather than consign material to the dumpster. Inverse pyramid style is your friend! -- Jmabel | Talk 08:28, 3 November 2005 (UTC)

Emphatically agree with William Pietri. By my count there are 15 pages of "what it is" or "how to", and 3/4 of a page of "Criticisms". The ratio should be more like 3 to 1, IMO.

I also noticed that a badly needed section that's currently missing is "real life situations". Who has actually used it most prominently? What were the results? Are any surveys available from any source that talk about satisfaction with this process after having actually completed at least one project? Any defectors who have renounced it forever? We can surely find some sharp criticism from people working on projects with totally defined goals and a 2-year budgeted timeline. Tempshill 17:34, 9 November 2005 (UTC)

I added a link to case studies to the external links section. (Note that the selection might be biased towards pro XP.) Ilja 20:40, 17 January 2006 (UTC)

Additional content

Fundamental content

fdiotalevi: I think that this article is totally missing to enunciate clearly the fundamentals of XP. First of all the four values: communication, simplicity, feedback and courage; and then pratices: some of them are actually mentioned, but without a precise order and often with inaccurate names. Check Kent Beck Extreme Programming Explained

Topics from 2006

Controversial aspects

The bullet point "Requirement and design specifications are not created or maintained" sounds misleading to me: XPers typically see the Automated Customer Tests as their detailed requirements specification, which naturally are very closely maintained.

I'm not sure how to incorporate this into the article, though. Ilja 09:31, 8 January 2006 (UTC)

I think it is appropriate to say that Automated Customer Tests play the role of a requirements specification, but having experience with both more traditional specifications-based approaches and Agile methods, I'd definitely say the two are not interchangeable. -- Jmabel | Talk 04:36, 9 January 2006 (UTC)

I disagree. In terms of the CMMI, Automated Customer Tests play the role(s) of Validation (did we build the right thing?) and Verification (did we build the thing right?), not Requirements Management or Requirements Development.

Taken collectively, the Automated Customer Tests, when finished, embody the requirements of the application. However, when finished, the application itself also embodies the requirements of the application. And we certainly wouldn't say that "the application software itself plays the role of a requirements specification", would we?

I would suggest that the on-site customer herself plays the role of the requirements specification. It's just that the document is locked up in her head, instead of written down.

Consider an automated teller machine (ATM) project. You're a developer and don't know if there should be a logging or audit trail facility for transactions. So you need to ask "Do we need to log transactions?" Likely the Automated Customer Tests don't have a test for this, and so are no help either way. However, your on-site customer will know the answer to this question; be it yes or no.

Now, an XPer might say, "Well, if there's no Automated Customer Test, that means there is no requirement." But this is akin to saying, "Well, if I'm not hungry right this second, that means there is no requirement that human beings eat." In other words, treating the Automated Customer Tests as the requirements specification is the "head in the sand" approach to requirements; they do or don't exist independently of having been codifed in a test or not. /* Pradeep Arya 06:08, 9 January 2006 (UTC) */

You have just summed up what I most dislike about XP: neither the User Stories nor the Automated Customer Tests usually make a serious attempt at comprehensiveness. For some types of systems, that's OK; for others (such as those where there are legal requirements, or where security is an issue) it seems to me to be a recipe for disaster. -- Jmabel | Talk 00:00, 10 January 2006 (UTC)

Jmabel, frankly I'm not sure that this discussion really helps us improve the article. After all, it shouldn't be about what I like or you dislike. Let's discuss the basic facts here - if you are interested in a discussion of your points, you can find me in both the XP usenet and Yahoo group forums. Ilja 20:24, 17 January 2006 (UTC)

Ilja, I would think that my own published views on the topic would be considered reasonably citable. - Jmabel | Talk 21:35, 21 January 2006 (UTC)

Pradeep, if the Customer can put a requirement in a requirements document, he can also write a test for it, and XP would require him to do so. If he doesn't do it, I'd argue that he likely also wouldn't have written anything about it in the requirements document, so you had to ask him anyway. (A fit team probably would have done that in the Iteration Planning Meeting, and reminded him of writing the tests.) Perhaps we should simply state that the requirements are represented by a combination of the Onsite Customer and the Customer Tests? Ilja 20:24, 17 January 2006 (UTC)

No. Tests are neither the requirements nor the requirements specification. Consider two situations.

Situation 1: A throughly evil XP Coach mandates "No automated tests!" - Is it possible to discover software requirements in this situation?

Situation 2: A throughly evil XP Coach mandates "No communication with the customer!" - Is it possible to discover software requirements in this situation?

I think the answers should make it quite clear which aspect of XP is "the requirements".—Pradeep Arya (Talk | Contrib) 12:40, 31 January 2006 (UTC)

New requirements come from the customer. In XP, they are documented in tests. In a traditional process you document them on paper, a document generally called "the requirements". In either process, you can check particular requirements against either source. In both, when the source conflict, the human source wins, and the textual source is updated to match. The main difference is that in XP, the requirements are automatically validated on at least every checkin. -- William Pietri 02:37, 1 February 2006 (UTC)

I think it is fair to say that "requirements and design specifications are not maintained" is a common fear, but it's not one that people who do XP would consider a controversial aspect, as they don't believe it's an aspect of XP at all. Two related things that might qualify as controversial aspects are that a) requirements are generally expressed as test cases, not documents, and b) requirements are defined incrementally, rather than trying to get them all up front. Pradeep and Jmabel, would a change like that adequately express your view of things? Or would moving the phrase at issue to a "common concerns" section be better? -- William Pietri 21:07, 23 January 2006 (UTC)

I think your two points here would qualify as a good expression of two controversial aspects. This is particularly the case for mission-critical systems, where money—or lives—can be lost in system failures. I remain totally unconvinced the XP can ever be made relevant to such systems. - Jmabel | Talk 22:08, 28 January 2006 (UTC)

Ok. I have made the change. Regarding your questions about XP and mission/life critical systems, I'd suggest extremeprogramming@yahoogroups.com is a better place to address them. Here I'd rather focus on just editing the article. -- William Pietri 03:56, 30 January 2006 (UTC)

Current state

Would it be appropriate to mention the regular international conference(s)? Ilja 09:39, 8 January 2006 (UTC)

I think it would be an appropriate external link, especially if the conference(s) are "official". /* Pradeep Arya 12:03, 8 January 2006 (UTC) */

Done. Ilja 20:31, 17 January 2006 (UTC)

Incomprehensible sentence cut

"One of the most tangible benefits is the development time across all the instances of the design implementing parameters to solve the issue." -- Jmabel | Talk 02:36, 11 January 2006 (UTC)

But, what IS it?

I have no experience with XP, so my contribution is as the naive reader. In this respect the article is lacking: I read the first several paragraphs and still had no idea what XP is. Perhaps this is consequence of the domain, rather than a fault of the article, I don't know. In any case, I found the article dissapointing. —The preceding unsigned comment was added by Osmodiar (talk • contribs) 11 Jan 2006.

oops, forgot to sign, sorry. Still trying to figure out what XP is. Osmodiar 01:58, 17 January 2006 (UTC)

Can you be more specific? When you read the definition in the lede paragraph, what does it not tell you about XP? Do you want a simpler definition? or something more elaborate and, ahem, definitive? → (AllanBz ✎) 09:28, 18 January 2006 (UTC)

The article is a mess - ironically because it is broken down into so many subsections -- most of which seem to be labelled according to trivial and overly particular terms. Instead of overorganization, be explanatory. Dont use header sections for one sentence paragraphs, or better yet dont use section headers for single paragraphs at all, unless they have meat. Use bullet lists instead. -Ste|vertigo 04:49, 1 February 2006 (UTC)

Thanks for speaking up! I appreciate the feedback. -- William Pietri 03:47, 3 February 2006 (UTC)

Ste, this is a different charge than Osmodiar's, so it probably ought to be in a new or different section. But, seeing as you've come up with a solution, why not Be Bold and edit the article along the lines you laid down? → (AllanBz ✍) 08:16, 3 February 2006 (UTC)

Oops! I guess you did. But... ugh. I'm reverting. Extreme Programming is never referenced without capitals in any publication that considers it seriously. I find "In software engineering..." (and similar constructions in articles where there is no need to disambiguate) vacuous—no alternatives, such as "In television, extreme programming..." exist, so why preface the definition, implying that the term exists in other fields? I believe that leaving several third-level headings without a second level heading is a Wikipedia heading style violation. → (AllanBz ✍) 09:05, 3 February 2006 (UTC)

"In any articles that considers it seriously" is a value judgement which doesnt really mean anything here. If articles do use it in a generic sense, then that in fact shows that the term has become publicised and has been adopted into the common language. This usage would transcend and include any proprietary methodology, even if its an original incarnation. It may be a bit too recent so its fine to keep the capitalised form, but its rare that any pair of common words can be proprietarised. See metadata for example. Despite the fact that you dislike the "in software engineering" convention, that convention nevertheless has been a way in which Wikipedia articles have been written for a couple years now. Granted there are topics which are too general or multidisciplinary to do so (fallacy for example), but this doesnt appear to be the case. If you want to revise the WP:MoS, please do so there. You make some odd claim that my suggestion is a "heading style violation", when in fact all I said is that the article should have substance and not merely be an outline. Use bullet lists instead, and dont make sections of any heading until theres enough matter to justify it. Thats what the thrust was. -Ste|vertigo 06:29, 6 February 2006 (UTC)

• "If articles do use it in a generic sense" — but they do not, in neither reputable journals nor trade industry rags. Extreme Programming, when it refers to the methodology discussed in the article rather than programming taken to an extreme, is always capitalized in any article that discusses it. So no value judgment is here involved; if you have references to the contrary, we can hash them out on the Talk.
• "In the software engineering" may be common Wikipedia usage, especially in terms with multiple usages, but it is not a mandatory nor even a recommended style, and need not be rigidly enforced, especially when the sense is plain and unambiguous. I stand by the revert. I think these last two points come down to your belief that extreme programming is a generic term, when its usage here refers to a defined, concrete methodology with a raft of literature behind it, both for and against, but always capitalized.
• "some odd claim that my suggestion is a 'heading style violation'" — I made no such claim about your suggestion. My claim was that one of the article changes you made, removing the second-level History section, was a heading style violation, because it orphaned the third-level (H3) Context, Origins, Current, Future Directions headings under the main article (H1). You should have converted them all to second-level headings, or followed your own advice and condensed them under a single second-level heading. My further edits after my revert kept the second level heading, but reduced the number of third-level headings, increasing the density of paragraphs-per-heading, as you suggested. In fact, I implemented your suggestions throughout much of the article as well, removing headings volo-nolo in favor of bullet lists and straight text.

Anyway, I found your suggestions to have great merit, and implemented them as much and as best I could throughout the article. I merely found the lede re-write to be infelicitous. I have tried to address Osmodiar's and your concerns with the lede by making a small rearrangement and adding a new sentence. No offense was intended, and I hope none was taken. → (AllanBz ✍) 10:01, 7 February 2006 (UTC)

Vandalism

3 vandalisms requiring 2 reverts in 1 day is too many. I've put the Sprotected template on the main page. If you disagree feel free to remove it, but be prepared to be vigilant about vandals yourself. --David.alex.lamb 20:31, 26 February 2006 (UTC)

Yet another not-logged in person changed the page, though in an OK manner this time. I guess the Sprotected template doesn't work the way I thought it did. --David.alex.lamb 18:17, 28 February 2006 (UTC)

To semi-protect a page, you must be an administrator. The sprotected template is merely a way of explaining that the page is semi-protected, it doesn't actually protect the page. I've removed it. Jude(talk,contribs) 09:56, 1 March 2006 (UTC)

Thanks. If there's more vandalism I guess I'll need to figure out how to contact an admin. --David.alex.lamb 17:49, 1 March 2006 (UTC)

Best place to contact an admin regarding this would be requests for page protection, but as the vandalism has been only mild and easily reverted, I don't think it really fits the criteria of being semiprotected. Jude(talk,contribs) 23:54, 1 March 2006 (UTC)

Come on guys, just do it right. This article is very weak and not simple enough. —Preceding unsigned comment added by 84.97.247.194 (talk) 06:04, 12 January 2008 (UTC)

Start Fresh in Joint Sandbox?

Hi. The issues with this article bother me, but when I look at cleaning it up, I find the length and number of issues overwhelming. What would people think of starting a fresh sandbox version and seeing if we can gradually build a small article up to be a good one of the proper size? Once the sandbox copy seems better, we can replace the current one. --William Pietri 18:36, 23 May 2006 (UTC)

No real objection, but please do see if some of what is here is at least worth cannibalizing. Also, once we flip over, we should probably keep a note on the talk page pointing to the last version before the change, since it will constitute an essentially different article that someone may want to access. - Jmabel | Talk 16:04, 5 June 2006 (UTC)

Disagreement over "new start"

William took the issue to the XP mailing list. I'm in complete agreement with rewriting the article, but I'm not a regular Wikipedia editor so the procedures are quite new to me. (I've done one edit before, in a completely different area.) -- John Roth (XP mailing list associate moderator.)

Hi, John. thanks for stopping by. You should probably start by reading WP:5P and WP:EQ and getting yourself an account.

To other editors, I should point you to the message [2] that drew John here and explain my intention in posting it. Normally I work on articles where I'm much less involved in the topic than Extreme Programming, as I find it much easier to be NPOV when I don't have much POV to begin with. However, this article has been in rough shape for so long that I've reluctantly decided to try building an alternative version despite my fear of unintentional POV bias. My post to the main Extreme Programming mailing list was the beggining of a search for reliable sources that document XP as practiced. The goal was definitely not to draw in people with a strong POV on the topic. John, that doesn't mean that I'm trying to discourage you from contributing. It's just that with a potentially contentious topic like this we'll have to be exceedingly careful to keep our personal biases out of the article. --William Pietri 23:08, 29 June 2006 (UTC)

I disagree strongly with any notion of putting up one person's version of Extreme Programming, especially when no clear articulation of the "problems" with the article has been made. "Rough shape?" Why should we trust your account of XP if you are not willing to put your concerns explicitly in the Talk first?

I think the onus is on you people to say exactly what's wrong with the article and allow the community who did care enough to write the article as it stands to decide upon the merits of those changes. Why do our edits have to disappear for some autocratic "this-is-the-way-I-see-it" alternative version, written in the dark?

I worked long and hard on Extreme Programming, adding, changing, and defending, with considered edits that have stood the test of time—the history section is unchanged in its essentials from the original edits. They stood the test of time because I respect the greater Wikipedia community, familiarized myself with good WP writing, and trusted other Wikipedians to let me know when I err. If you want to make changes, you can certainly make changes within the framework of the community. So:

No alternative versions! This community of interest has been receptive to changes in the structure and content of the article. I myself bent over backwards when someone made specific recommendations on the Talk Page comments—see above. Make your edits, make your proposals, but do not flip the article for a new one created without community input. Work from the article and the talk pages or not at all.

So, back to trust. The comments you made above do not lead me in any way to trust your plans for the article. You'll have to win our trust back.

→ (AllanBz ✍ 07:30, 12 July 2006 (UTC)

Can someone clarify what the problems are? Why is the article in "rough shape"??? Is it the structure of the article? Perhaps drafting a new table of contents is the starting point, then we can refactor the existing text under the new headings and then fix or fill out the sections in worst shape. Stumps 10:04, 12 July 2006 (UTC)

Hi, Allan. I'm sorry you're upset, and I believe you're reading a lot more into my proposal than is there. I am of course not interested in "one person's version" of Extreme Programming. I want a readable, cited, NPOV article, and want it jointly produced by as many people as possible. Note the liberal use of "we" above, note also that I proposed doing changes in a sandbox so that we could see what radical changes looked like without touching the current article. I am far from unwilling to put my concerns in the talk page; if you'd like to know what they are, you don't have to stridently impugn my intent and motives; you can just ask. In fact, you don't even have to do that; I'll take this as a request, and I'll put together a list by and by. Also note WP:OWN; that this is a joint effort applies to all parties. William Pietri 15:11, 12 July 2006 (UTC)

If my tone be excited and strident, it is only because no one was writing against the idea of a radical change made outside the normal, visible process of article editing, and I felt the strongest wording necessary. I see no list yet: at least bring up the roots of your concern with the article, so everyone can mull the issues involved. (Where my tone seemed strident, your tone strikes me as disparaging, though I am certain that is not the case.) → (AllanBz ✍) 01:21, 16 July 2006 (UTC)

C3 project cancellation

The "History" section says "Chrysler cancelled the C3 project in February 2000," without any further elaboration. If I don't misunderstand the discussion on WikiWikiWeb, then C3 was actively used for the payroll of about 9000 Chrysler employees at the time the development was stopped. I am probably reading too much into this, but to me the "History" section as it stands now makes the C3 project sound like a complete failure, and I am not sure if this is an objective portrayal of what happened. — Tobias Bergemann 08:25, 29 September 2006 (UTC)

That matches my understanding. Why don't you propose a change to the article here? William Pietri 16:16, 29 September 2006 (UTC)

I see that the reference we cited on this project has gone away. I've snagged a copy from the Google cache, and asked the professor whose site it was on for permission to re-post it. It definitely describes a "mixed bag". For example (these paragraphs are not consecutive):

The project was cancelled in January/February 2000 becauase it was only paying one-third of Chrysler employees, the Y2K period had passed and the mainframe software was still operating correctly, and the project was over budget.

This project was initially considered a success. There was this software project bogged down by a dinosaur-like process model. Then comes XP and voila! partial success. XP was dynamic enough to allow the project to move on; it was also focused on functionality which meant that success was guaranteed, if only on a small scale.

The truth of the matter is that the project failed to pay all 87,000+ employees at Chrysler and was, therefore, just as much of a failure before, during, and after XP. One of the reasons for this failure is described by Jawed Siddiqi, who said, "The troubles the C3 project later encountered, due to communication problems between the development team and the two sets of management stakeholders (the IS department which was the customer, and the Payroll Department which was the user) present significant concern because communication between the customers and the team lies at the heart of XP’s approach." Doug Rosenberg and Kendall Scott describe a weakness within XP itself that may have lent to the downfall of C3: feature-itis. Because requirements can change several times a day, meeting the requirements isn't the goal. Without this focal point, the project can take on a life of its own and keep growing without ever reaching its conclusion...especially if there are two customers, as in the case of C3 (IS and payroll).

(All from the now-deleted http://www.ics.uci.edu/~ses/teaching/ics121/histories/hherela/index.html as retrieved on Mar 25, 2006 20:11:52 GMT). - Jmabel | Talk 22:00, 1 October 2006 (UTC)

At my request, Susan Elliott Sim of U.C. Irvine has re-posted Harvey Herela's remarks on the Chrysler Comprehensive Compensation System, this time at a URL that should be permanent. We should be able to cite this in the article, and amost certainly should. - Jmabel | Talk 07:12, 2 April 2007 (UTC)

It looks like the citation approach of the article is currently a mess. I'll add this to the references, but it's someone else's problem to work out how to get it into the inline citations. - Jmabel | Talk 07:15, 2 April 2007 (UTC)

IXP

The link here for IXP appears to be to the company that came up with it and is promoting it. Is there independent citation for it being notable? - Jmabel | Talk 07:33, 9 November 2006 (UTC)

No that I know of. I saw IXP on their site. It looks like pretty good idea, so I placed link here so others could see original idea.--Littlesal 01:56, 14 November 2006 (UTC)

The thing is, we don't normally link things just because they're cool, we link because they are notable. - Jmabel | Talk 07:28, 16 November 2006 (UTC)

You are right of course, but Cutter Consortium is important in XP community. Its researches are quotated in couple of books about XP that I read, and IXP is their own invention. It is based on XP and also is a new member of Agile family which is extensible. This link is not a spam, I have nothing to do with them. It would be spam just if the link to Rational about RUP is. Maybe it didn't passed test of time yet, but it definitly have potentials to win against some XP faults: using it in big teams, and in distributed organisations. So I admit that it was little jumpy to put it in the evolution chapter, but on the other hand it EVOLVED from XP, there is no doubt about that. So you can delete that entry if you really think it brake some rules, but just read original article about IXP first, it is extreme version op XP ideed :) Littlesal 20:43, 18 November 2006 (UTC) - If someone want to help me biuild an IXP article you are welcome to come on my user/talk page.

Short definition of XP

Can someone help me with short definition. I want to try defining XP and then put it in header of article. The first version of the definition is

 Ekstreme programiramming(XP) is an agile organisational pattern lenguage 
   which is used in team software development. It is made of sinergy of 
   team values and principles wich support these values through practical 
   mechanisms of team-work functioning and team activities. The goal of 
   this sinergy is high level of product quality and change response.

It may be wrong in style, or in grammar because for me English is foreign lenguage. Maybe it is wrong acording to someone. I think that using term methodology, or method is wrong because this is pattern lenguage. Please write some comments --Littlesal 02:11, 14 November 2006 (UTC)

Sorry, but its not just the very wrong spelling. This is absolutely incoherent. - Jmabel | Talk 07:29, 16 November 2006 (UTC)

Can you or someone help me reorganize it if you agree to its content? Here is repeated definition where everybody could make changes(please keep first one unchanged):

Ekstreme programiramming(XP)

is an agile organisational pattern lenguage which is used in team software development. It is made of sinergy of team values and principles wich support these values through practical mechanisms of team-work functioning and team activities. The goal of this sinergy is high level of product quality and change response.

Perhaps you can explain what you think is wrong with the current lead? As things stand I'm unsure why you want to change it in the first place. Thanks/wangi 19:26, 16 November 2006 (UTC)

Well, XP isn't metodology, it is pattern, and these concepts are in conflict. OK, we can call it metodology just to be less misterious because concept of patterns is new, and someone don't need to know it if he want to understand XP. One sharp and short definition could be at the start of this article, just to maintain scientific nature of wikipedia, and to make article piramidal in form. I am not saying that article is wrong or bad, I just want to make it better if I can. I am working now on my master degree final exam papers about XP and came up with this definition. I would like to share it with community, but first, want to check its integrity as someone has recommanded to me. It isn't important to be in header, but it is logical to me if it represents in short all that will be written later in detailed text.

Kent calls it a methodology. Remember that he is a major contributor to the patterns literature, if he wanted to call it a pattern he would have. Regards, Ben Aveling 06:50, 18 November 2006 (UTC)

He called it methodology back in 1999. when he tried to prove XP is working, and didn't need conflict with wider community. Well, he proved his point and I bet he would call it pattern language now, not a methodolgy. I have heard James Coplien about pattern languages in some lectures about patterns here in Belgrade in 2004. when I didn't even heard about Agile and XP. Once I started to analyze XP it became clear to me that it is just what he talked about back then. He mationed somthing like: All methodologists are tirans, and methodologies are tirany, patterns are somethig different in its nature. It is now clear to me what he was talking about, but back then I was not so sure. The fact that XP was formed on Ward Cunninghams Portland Pattern Repository adds some points to this perspective. After all Kent Beck and Grady Booch made hillside group back in 1993. Beck was one of the fathers of patterns (with Booch, Cope, Cunningham, Ralph Johnson, Ken Auer and Hal Hildebrand, and others like GOF, and Cristopher Aleksander as forefather), he was wisely evading the term patterns, just not to get in argument about not so important staff at that moment. I think now is time to get open about that theme and it would be so nice to ask Beck himself about that, I'll ask Cope instead and let you know. - Littlesal 20:47, 18 November 2006 (UTC)

Erm, remember we must use published sources - not individual investigation. See WP:V. Thanks/wangi 00:14, 19 November 2006 (UTC)

Checkmate, I didn't know about it. Well I guess I'm just lammer for this wikipedia thing. It have a lot of sence just to accept already published facts. I was hoping that evolutionary designed definition of XP would be perfect. But, I heven't told you that there are some methodologys just to define patterns ;) GOF way is one of them, but here it should be used Alexanders method for defining XP. Well it is past now, I give up :~( - Littlesal 02:28, 19 November 2006 (UTC) PS:I've just saw an headline in above text:But, what IS it? And discover that maybe there are needed to have an short definition in header. Please consider this definition even if it isn't published yet, but it is verifiable, because it doesn't conflict with text of article that follows. I think that our discusion could be continued on my talk page: LittleSal.

• What about fifth pillar of wikipedia, and why administrators are so overprotective over this article? Let it live. XP also lives and changes. Littlesal 17:42, 26 November 2006 (UTC)

This an encyclopaedia, not a personal research project. We cannot ignore the core policies of verifiability, No original research and neutral point of view. Thanks/wangi 17:46, 26 November 2006 (UTC)

Topics from 2007

Well, no.

"The most controversial aspect of Extreme Programming is the change management aspect of the process. More formal software development processes require change requests to be analyzed and approved by a change control board (or equivalent). In Extreme Programming, the on-site customer requests the changes informally, often by verbally informing the development team."

This is so wrong, I don't know where to start. It totally misses the planning game, which does everything that this paragraph says doesn't happen. And for sure, there are plenty of controversial aspects, claiming any one as the most controversial is pure speculation and OR. Regards, Ben Aveling 09:40, 6 April 2007 (UTC)

Fixed-price projects go hand-in-hand with CCBs, so I would rather say that CCBs are a formality of fixed-price projects. Because of the emphasis of sorting bugs from features (Change Requests), a CCB can be considered an extension of contract negotiation. Since XP doesn’t claim to be suitable for fixed-price projects I don’t see how it can be controversial that it doesn’t do CCBs. --ChrisSteinbach 18:46, 10 April 2007 (UTC)

No more discussion has followed after a month. I guess that's long enought to wait so I cut the text. Here is is if someone wants to argue to put it back in: --ChrisSteinbach 19:22, 10 May 2007 (UTC)

"The most controversial aspect of Extreme Programming is the change management aspect of the process. More formal software development processes require change requests to be analyzed and approved by a change control board (or equivalent). In Extreme Programming, the on-site customer requests the changes informally, often by verbally informing the development team."

Adaptation and prediction

Cut from intro:

Like other agile methodologies, Extreme Programming differs from traditional methodologies primarily in placing a higher value on adaptability than on predictability.

This idea is not found in Kent Beck's book and appears false on its face. XP as decribed by Beck places a high emphasis on predictability. Programmers routinely predict how long it will take to develop a feature; then they measure actual development time, so that they can refine their ability to make such predictions.

The value of prediction (of how long a feature will take to develop) is that the customer gets to choose which feature(s) to develop first. The customer will typically choose to delay a low-priority feature which is predicted to take a long time to develop; or to accelerate a medium-priority feature which has an unexpectedly low predicted development time. --Uncle Ed 15:10, 9 May 2007 (UTC)

Hi, Ed. As an XP coach I'm of two minds on this. I think if you asked XP adoptees whether they preferred adaptability to predictability, they'd say that they would favor the former. On the other hand, I think it's a false dichotomy. Our approach to prediction involves continuous adaptation, so a good XP team can predict schedules very well after they've gathered some velocity data. What we don't pretend to predict is what the actual features chosen will be or what the architecture will be. That is a big difference from waterfall-derived approaches, which make a lot of attempts to predict things up front.

So if I were looking for a phrasing of that I could live with, I'd say that Extreme Programming, like other agile methods, focuses more on being adaptable than betting on our ability to predict the future. Barry Boehm has another description: traditional methods are plan-driven, whereas agile methods are planning-driven. Rather than trying to make one plan and stick to it, they continuously re-plan as information arrives. Hoping that helps, William Pietri 01:48, 11 May 2007 (UTC)

I think perhaps what was meant is predictability in the process, although I would have preferred the word repeatability in that case. I've never quite grasped why software developers would aim for repeatability, and the word encapsulates for me much of the misguidedness I associate with traditional methodologies.

There is a certain amount of repeatability in XP, but I would characterize the process as one where situations are recognized and responded to. Contrast this with a process that says "day 1 – Nail the requirements to the desk; day 2 – Write a design document to prove you actually read the requirements; day 3 – Read the requirements…." and so on. --ChrisSteinbach 21:00, 11 May 2007 (UTC)