Slashdot Mirror

Then you don't understand the whole approach. XP evolved by taking good programming practices (automated testing, peer code review, "integration builds", client communication, etc.), and kind of going overboard with them. As a result, it typically generates higher quality deliverables. For example, in XP, before you write code, you write the test first. Instead of weekly code review meetings, you code with someone else. Instead of everyone writing their code in isolation, then slamming it together to see if it all works, you see if your code works together all the time. Instead of waiting for one or two business days to get a requirement clarification from the customer, you get that information from them much sooner.

There are more practices such as these that make up XP. I've worked on many projects, particularly with the big consultancies, that use waterfall-type methodologies that fail. A 600 page design document is useless when the requirements change during the project, which they always do, due to market demands, time constraints, etc. XP is no silver bullet, but it makes a lot of sense after you've been through lots of projects that go over budget, without all the desired features, even after working 80 hour weeks.

Then you don't understand the whole approach. XP evolved by taking good programming practices (automated testing, peer code review, "integration builds", client communication, etc.), and kind of going overboard with them. As a result, it typically generates higher quality deliverables. For example, in XP, before you write code, you write the test first. Instead of weekly code review meetings, you code with someone else. Instead of everyone writing their code in isolation, then slamming it together to see if it all works, you see if your code works together all the time. Instead of waiting for one or two business days to get a requirement clarification from the customer, you get that information from them much sooner.

There are more practices such as these that make up XP. I've worked on many projects, particularly with the big consultancies, that use waterfall-type methodologies that fail. A 600 page design document is useless when the requirements change during the project, which they always do, due to market demands, time constraints, etc. XP is no silver bullet, but it makes a lot of sense after you've been through lots of projects that go over budget, without all the desired features, even after working 80 hour weeks.

Then you don't understand the whole approach. XP evolved by taking good programming practices (automated testing, peer code review, "integration builds", client communication, etc.), and kind of going overboard with them. As a result, it typically generates higher quality deliverables. For example, in XP, before you write code, you write the test first. Instead of weekly code review meetings, you code with someone else. Instead of everyone writing their code in isolation, then slamming it together to see if it all works, you see if your code works together all the time. Instead of waiting for one or two business days to get a requirement clarification from the customer, you get that information from them much sooner.

There are more practices such as these that make up XP. I've worked on many projects, particularly with the big consultancies, that use waterfall-type methodologies that fail. A 600 page design document is useless when the requirements change during the project, which they always do, due to market demands, time constraints, etc. XP is no silver bullet, but it makes a lot of sense after you've been through lots of projects that go over budget, without all the desired features, even after working 80 hour weeks.

Then you don't understand the whole approach. XP evolved by taking good programming practices (automated testing, peer code review, "integration builds", client communication, etc.), and kind of going overboard with them. As a result, it typically generates higher quality deliverables. For example, in XP, before you write code, you write the test first. Instead of weekly code review meetings, you code with someone else. Instead of everyone writing their code in isolation, then slamming it together to see if it all works, you see if your code works together all the time. Instead of waiting for one or two business days to get a requirement clarification from the customer, you get that information from them much sooner.

There are more practices such as these that make up XP. I've worked on many projects, particularly with the big consultancies, that use waterfall-type methodologies that fail. A 600 page design document is useless when the requirements change during the project, which they always do, due to market demands, time constraints, etc. XP is no silver bullet, but it makes a lot of sense after you've been through lots of projects that go over budget, without all the desired features, even after working 80 hour weeks.

Then you don't understand the whole approach. XP evolved by taking good programming practices (automated testing, peer code review, "integration builds", client communication, etc.), and kind of going overboard with them. As a result, it typically generates higher quality deliverables. For example, in XP, before you write code, you write the test first. Instead of weekly code review meetings, you code with someone else. Instead of everyone writing their code in isolation, then slamming it together to see if it all works, you see if your code works together all the time. Instead of waiting for one or two business days to get a requirement clarification from the customer, you get that information from them much sooner.

There are more practices such as these that make up XP. I've worked on many projects, particularly with the big consultancies, that use waterfall-type methodologies that fail. A 600 page design document is useless when the requirements change during the project, which they always do, due to market demands, time constraints, etc. XP is no silver bullet, but it makes a lot of sense after you've been through lots of projects that go over budget, without all the desired features, even after working 80 hour weeks.

Then you don't understand the whole approach. XP evolved by taking good programming practices (automated testing, peer code review, "integration builds", client communication, etc.), and kind of going overboard with them. As a result, it typically generates higher quality deliverables. For example, in XP, before you write code, you write the test first. Instead of weekly code review meetings, you code with someone else. Instead of everyone writing their code in isolation, then slamming it together to see if it all works, you see if your code works together all the time. Instead of waiting for one or two business days to get a requirement clarification from the customer, you get that information from them much sooner.

There are more practices such as these that make up XP. I've worked on many projects, particularly with the big consultancies, that use waterfall-type methodologies that fail. A 600 page design document is useless when the requirements change during the project, which they always do, due to market demands, time constraints, etc. XP is no silver bullet, but it makes a lot of sense after you've been through lots of projects that go over budget, without all the desired features, even after working 80 hour weeks.

And I thought I was the only one actually using them.

I am not sure what you're getting at?

"Excuse me for making use of the English language. Besides, if it's a duck and all that, well..."

Again, I think you have a poor understanding of what "communism-type" and "dictatorship" are suppose to be about. That's not a fact, that's my opinion. You're entitled to your own opinion. You're even entitled to call your own dubious opinion a non-judgemental fact, so please don't feel obligated to "excuse" yourself for it (I was certainly not asking for your apology).

"Ohhhh, the classic 'if you don't like it, fuck off' or it's more popular variation 'stop complaining and [write some code|fork the source]' post. Hadn't seen that one in a while."

I understand why you may feel this is what I said. Reading it back myself, it sounds like this is what came out, but this is not what I meant. There is no sensible backpedaling on this one, I did a piss poor job at expressing my opinion. So here comes my retraction (for what it's worth).

First, to recap, here is what I said:

"In any case, you make a valid point regarding the lofty titles. Lofty titles are a sign of ego-driven organizations. Perhaps, now that you've pinpointed the problem, you could start your own branch called the 'EgolessBSD'?"

So here is what I wish I would have said:

Bungi, I think you're on to something. I've heard so many nonsensical self-agrandizing titles, I am really getting sick of them myself. Unfortunatly, "lofty" titles are not only the province of open source projects, really stupid "lofty" titles and really stupid acronyms can also be found in for-profit corporations. For example, I used to work for a department at a company that changed its name to the "World-Wide Consumer Insights Department", please don't ask me what it meant, I still haven't figured it out and I used to work there. In addition, if you look at the World Wide Web, a model of sorts for anarcho-capitalism, I think you'll find a plethora of really stupid "lofty" names all over the place. So in the end, I think "lofty" titles are ego-driven and not necessarily politically-inspired as you seem to imply.

Perhaps, someone could start an an open source egoless Operating System. The contributions could all be anonymous and noone would be given any credit for their work. The concept would work somewhat like http://c2.com/cgi/wiki?WelcomeVisitors , or http://c2.com/cgi/wiki?CollectiveCodeOwnership , and people would be discouraged to take credit or put initials next to their work. This would take care of the "lofty" title problem, since without a name, they wouldn't care about their title.

Personally, this is not something I would want to work on myself, since I am an ego-driven individual, but since this idea works somewhat for a good portion of the content on the WikiWikiWeb -- who knows? It could actually work for a BSD operating system.

I am not sure what you're getting at?

"Excuse me for making use of the English language. Besides, if it's a duck and all that, well..."

Again, I think you have a poor understanding of what "communism-type" and "dictatorship" are suppose to be about. That's not a fact, that's my opinion. You're entitled to your own opinion. You're even entitled to call your own dubious opinion a non-judgemental fact, so please don't feel obligated to "excuse" yourself for it (I was certainly not asking for your apology).

"Ohhhh, the classic 'if you don't like it, fuck off' or it's more popular variation 'stop complaining and [write some code|fork the source]' post. Hadn't seen that one in a while."

I understand why you may feel this is what I said. Reading it back myself, it sounds like this is what came out, but this is not what I meant. There is no sensible backpedaling on this one, I did a piss poor job at expressing my opinion. So here comes my retraction (for what it's worth).

First, to recap, here is what I said:

"In any case, you make a valid point regarding the lofty titles. Lofty titles are a sign of ego-driven organizations. Perhaps, now that you've pinpointed the problem, you could start your own branch called the 'EgolessBSD'?"

So here is what I wish I would have said:

Bungi, I think you're on to something. I've heard so many nonsensical self-agrandizing titles, I am really getting sick of them myself. Unfortunatly, "lofty" titles are not only the province of open source projects, really stupid "lofty" titles and really stupid acronyms can also be found in for-profit corporations. For example, I used to work for a department at a company that changed its name to the "World-Wide Consumer Insights Department", please don't ask me what it meant, I still haven't figured it out and I used to work there. In addition, if you look at the World Wide Web, a model of sorts for anarcho-capitalism, I think you'll find a plethora of really stupid "lofty" names all over the place. So in the end, I think "lofty" titles are ego-driven and not necessarily politically-inspired as you seem to imply.

Perhaps, someone could start an an open source egoless Operating System. The contributions could all be anonymous and noone would be given any credit for their work. The concept would work somewhat like http://c2.com/cgi/wiki?WelcomeVisitors , or http://c2.com/cgi/wiki?CollectiveCodeOwnership , and people would be discouraged to take credit or put initials next to their work. This would take care of the "lofty" title problem, since without a name, they wouldn't care about their title.

Personally, this is not something I would want to work on myself, since I am an ego-driven individual, but since this idea works somewhat for a good portion of the content on the WikiWikiWeb -- who knows? It could actually work for a BSD operating system.

I am not sure what you're getting at?

"Excuse me for making use of the English language. Besides, if it's a duck and all that, well..."

Again, I think you have a poor understanding of what "communism-type" and "dictatorship" are suppose to be about. That's not a fact, that's my opinion. You're entitled to your own opinion. You're even entitled to call your own dubious opinion a non-judgemental fact, so please don't feel obligated to "excuse" yourself for it (I was certainly not asking for your apology).

"Ohhhh, the classic 'if you don't like it, fuck off' or it's more popular variation 'stop complaining and [write some code|fork the source]' post. Hadn't seen that one in a while."

I understand why you may feel this is what I said. Reading it back myself, it sounds like this is what came out, but this is not what I meant. There is no sensible backpedaling on this one, I did a piss poor job at expressing my opinion. So here comes my retraction (for what it's worth).

First, to recap, here is what I said:

"In any case, you make a valid point regarding the lofty titles. Lofty titles are a sign of ego-driven organizations. Perhaps, now that you've pinpointed the problem, you could start your own branch called the 'EgolessBSD'?"

So here is what I wish I would have said:

Bungi, I think you're on to something. I've heard so many nonsensical self-agrandizing titles, I am really getting sick of them myself. Unfortunatly, "lofty" titles are not only the province of open source projects, really stupid "lofty" titles and really stupid acronyms can also be found in for-profit corporations. For example, I used to work for a department at a company that changed its name to the "World-Wide Consumer Insights Department", please don't ask me what it meant, I still haven't figured it out and I used to work there. In addition, if you look at the World Wide Web, a model of sorts for anarcho-capitalism, I think you'll find a plethora of really stupid "lofty" names all over the place. So in the end, I think "lofty" titles are ego-driven and not necessarily politically-inspired as you seem to imply.

Perhaps, someone could start an an open source egoless Operating System. The contributions could all be anonymous and noone would be given any credit for their work. The concept would work somewhat like http://c2.com/cgi/wiki?WelcomeVisitors , or http://c2.com/cgi/wiki?CollectiveCodeOwnership , and people would be discouraged to take credit or put initials next to their work. This would take care of the "lofty" title problem, since without a name, they wouldn't care about their title.

Personally, this is not something I would want to work on myself, since I am an ego-driven individual, but since this idea works somewhat for a good portion of the content on the WikiWikiWeb -- who knows? It could actually work for a BSD operating system.

http://c2.com/cgi/wiki?InSovietRussia

Believe what you wish, whether it is contrary to current practise or not. XML and RDF allow people to structure their content far better than alternatives, with less effort. Unless you have a better and more accessible way - why not mention it now, I'm interested in hearing about it.

i wasn't clear but youre ignoring the point. i meant to imply that XML isn't the problem. since i'm lazy, i'll just link this article.

There is no "still have to write". That's the beauty of XML based languages. You _don't_ have to write your own parser or renderer. These generic tools are already available and in use now

that's rather silly if youre trying to respond to what i said. and you can only get away with it by using necessarily vague terms like parser and renderer. but it might be my fault in part: by display, i certainly don't mean renderer, and by "do stuff" i don't mean parse as if the data were already magically structured to solve my problem. and that's how it's often touted.

"I was also hoping for more of a discussion on the practicalities of unit testing database-driven systems, where you frequently have to test business entities which are closely coupled to the database.

This is kind of like that joke: "Doctor, it hurts when I do this..." Seriously, avoid, where possible, coupling your classes (even persistent ones) to a database. The fact that you're having trouble testing these should tell you something about the quality of the encapsulation in your system.

It certainly was an eye-opener for my development team. We were working with an implementation of the Data Access Object pattern (Service class +value object + DAO = persistent component). What we found was that the further we got from the database, the more we were repeating tests. In other words,test that DAO can retrieve, test that it can write. Then test that the service can read, then that the service can write, and go check the database. Set up and tear down was a major pain, and only got worse, until...

We figured that we couldn't be the only ones to run into this issue. We started digging around the Wiki Wiki Web to find suggestions for how to factor our classes properly to make them easier to test. We turned up the Mock Object pattern. Basically, have the DAO implement an interface, then implement that same interface in your test. You now have a well factored class, and you can do setups and teardowns of data that doesn't exist.

Handling related instances is difficult, but that leads to the next refactoring... a domain model architecture with a service layer on top, and a o/r mapping layer underneath. But that's another story.

Hear it from the players players themselves.

One of the benefits of XP is that it can tell you much earlier about whether or not to terminate a project in the first place. From Extreme Programming Explained:

One of the features of XP is that customers can see exactly what they are getting as they go along.

I'd say the big deal is your guys spent 3 man months on something they could have just downloaded. There are 4 .Net/C# frameworks on this list, and 7 on this one.

The /. article describes Bill Venner's justification for writing his own; did your guys have a reason for what they did, or was it just "not invented here" syndrome?

Another question is how you could spend as long as 3 months on this at all, xUnit isn't complicated...they've just pissed away roughly £15,000-£63,000 of your customers money (depending on if they were permies or conslutants).

Creating SuiteRunner was a huge amount of work. Despite my frustrations with JUnit, it would have been orders of magnitude easier to decipher JUnit's source code than to create a brand new testing toolkit.

The other guy was Erich Gamma, of Design Patterns fame.

Sorry for a second post, but another awesome wiki with a more technical bent is at c2 dot com (I linked you to starting points). Another place where I've spent hours and hours and... aaah. Collaboration rocks.

• Extreme Programming
• Feature-Driven Development
• Scrum
• Crystal

So will the second version, and the third, and the fourth... In my experience, any code that isn't re-written often gets crufty and becomes increasingly worthless.

The more the code gets rewritten (a.k.a. refactored), the better it gets. Hmmm... so, what if you were to refactor it often? Very often? Extremely often?

If we accept this for the sake of argument, could it be that women get pissed off at debugging more than men? Anyone want to support or refute? My sample size of women is too small to draw conclusions.

Perhaps what we need is more pair programming in CS courses. It makes debugging less frustrating. (Also, for those of you who subscribe to the "women want more social interaction" philosophy, it provides that.)

If you don't have another programmer handy, try the practice of Rubber Ducking.

This is where when you are completely stuck, you take a little break. Then you come back, pull a rubber duck out of your drawer, and put it on your desk. Then you turn to it and say, "Rubber duck, here's my problem," and explain your troubles to it, just as you would to a fellow programmer.

About two thirds of the time I try this, I stop half way through and say, "Aha! That's the problem!" And even if the solution doesn't occur to me, the process of explaining the problem makes me go over it in an orderly way, so that I always think of new places to look.

Well, when you combine enough of your small functions/methods together into one big monolith of a program problems tend to surface. What then?

Then you haven't written enough tests. Or you're trying to integrate too much at once.

If you do test-first development and continuous integration (backed up with good black-box integration testing), then the number of bugs you get should be low. In my experience, that's circa one shipped bug per man-month.

If I run all the tests frequently as I develop and check in often, I rarely need a debugger. If I break a test, I generally know exactly what the problem is.

If I forget to run all the tests and check in, then the automated build box will send me email promptly, so it's still pretty easy to find the problem.

It is essential, like an x-ray / CT-scan / ultrasound is to a surgeon.

Note that the only time you see a surgeon is when something is pretty seriously wrong. Isn't it much better to make sure that things don't go so far wrong that a surgeon is necessary?

Well, when you combine enough of your small functions/methods together into one big monolith of a program problems tend to surface. What then?

Then you haven't written enough tests. Or you're trying to integrate too much at once.

If you do test-first development and continuous integration (backed up with good black-box integration testing), then the number of bugs you get should be low. In my experience, that's circa one shipped bug per man-month.

If I run all the tests frequently as I develop and check in often, I rarely need a debugger. If I break a test, I generally know exactly what the problem is.

If I forget to run all the tests and check in, then the automated build box will send me email promptly, so it's still pretty easy to find the problem.

It is essential, like an x-ray / CT-scan / ultrasound is to a surgeon.

Note that the only time you see a surgeon is when something is pretty seriously wrong. Isn't it much better to make sure that things don't go so far wrong that a surgeon is necessary?

In that case, keeping everything in RAM in Java objects is hundreds of times faster than fetching from a database.

Actually, the history of C# doesn't have as much of a direct link to Java as you might have expected.

ThirdVoice, now defunct.

Then you should spoil your ballot, which is perfectly legal.

[TMB]

• It seems to require some failing tests that are to be fixed before you can create a development branch. How does this mix with refactoring? Do you have to invent a test for "This piece of code should be more elegant", or what?
• Is it possible to integrate the mandatory testing with an existing testing framework like one of the xUnits? Writing a shell script for each test case seems to be stupid.
• How about IDE integration? An Emacs mode?
• In general, what if I don't like something about the process it wants to enforce? Is it flexible enough to be adapted to local policy? Is it really a good idea to couple revision management and workflow? (It surely is not the "Unix way", which it like to integrate well with)

My quick intro: http://www.kuro5hin.org/story/2002/11/14/22741/791

A wiki entry written by David Ness: http://www.c2.com/cgi/wiki?KayLanguage

The end of OS/2 was spelled out clearly on August 17, 1995, when OS/2's original chief architect, Gordon Letwin, described its insurmountable barriers in this posting to comp.os.os2.advocacy.

every page could be if every page were a wiki.

every page could be if every page were a wiki.

every page could be if every page were a wiki.

every page could be if every page were a wiki.

every page could be if every page were a wiki.

every page could be if every page were a wiki.

every page could be if every page were a wiki.

every page could be if every page were a wiki.

every page could be if every page were a wiki.

every page could be if every page were a wiki.

Regarding OO and resue. Most "in the know" practitioners *don't* seem to rank "reuse" as the most important aspect of OO. Here is some comments about it:


http://c2.com/cgi/wiki?ReuseHasFailed

And here are some of my comments and observations about OO and reuse:


http://www.geocities.com/tablizer/reustalk.htm

One problem I have seen trying to make "generic software tools" is that to make them truely generic it seems one has keep adding features and bloating up the interface to cover all possible wants of each client (user). After a while it becomes almost easier to build you own from scratch or copy some base code and modif it than to navigate and use the complex interface. Copy-and-modify seems less full of worms than reference-based reuse.

IOW, copy-reuse works, reference-reuse does not, at least not for business logic. However, software engineering "rules" seems to prefer reference-reuse. Duplication is generally considered "bad". Understandable, but in practice it is not easy at all.

As far as what the benefits of OO are supposed to be, I get different answers from different OO fans, many of them vague IMO. I give up. I don't know what the benefits of OO are supposed to be. The top candidates seem to be either that it reduces the impact to the code of changes in requirements, or improves the human grokkability of the result. I have not seen any good code evidence of the first and the second is subjective because different people grok differently.

This whole OO thing puzzles me to no end. I don't get it. The shape, animal, and device driver book examples don't extrapolate to custom biz apps. I am either busted upstairs, or OO fans are mistaking subjectivity for objective benefits. I don't really question that it may fit thier head better, but I don't own their head.

Slashcrunch comments: "mouse/keyboard (Controller) MVC... umm... the C doesn't equate to keyboard or mouse. M = Model - business objects and such V = View - presentation, web pages etc. C = Controller - code, in this case a Servlet that decides what is to be done And now back to your coffee :)"

See this discussion of MVC, where it states "A controller offers facilities to change the state of the model." The idea back in the late 70s was to allow the computer user to select the most appropriate control interface to address his or her possible disabilities.

That is why refactoring by itself is no silver bullet, and noone is saying that it is. At least, noone that has any insight. It is, however, a great tool to meet the changed requirements.

You have to Embrace Change, and in that refactoring will really, really help you a lot.

If requirements change so much it is not the same program anymore, well, then I'd not say that requirements have changed in the project. It is a whole new project, right? And then, of course, no rewrite will help you.

But if they change a lot within the same functionality, you use refactoring to get to the new goal without breaking anything, and because you have been refactoring out good interfaces as you went the changes are easier to implement. You do not code for two months, then refactor for two, the code etc. You do both all the time.

I think you are missing the point here.

Named parameters are nice as well, this is an alternative which has its advantages and disadvantages. If I had to choose I would go for the refactoring(s). They are more versatile, encourage improving your code and save some find/replace (well, a lot actually).

I consider refactoring one of major new OO coding techniques of this decennium (some things might work with procedural programming, but a lot of refactorings are OO specific). If you want to learn more, you should read Ward Cunninghams famous wiki and check out refactoring.com (although it's a bit hard to navigate).

...and then requirements change, and you are up shit creek. That is still waterfall design.

Better take a look at doing requirements, design and architecture via the planning game instead, which means there is an iterative process instead.

You can thank me later. ;-)

...and then requirements change, and you are up shit creek. That is still waterfall design.

Better take a look at doing requirements, design and architecture via the planning game instead, which means there is an iterative process instead.

You can thank me later. ;-)

Her breasts weren't *that* large, I think that bizarre suit they whipped up for her was responsible for half of it. As a sex symbol (an icy one) she was OK, but I intensely disliked the ridiculous high heels they had her wear. (Look like I'm not the only grump about this point. One fan insists the heels are "irony" :)

I just read Koenig/Chekov's book "Warped Factors" from the library. It's fairly entertaining and talks some about Roddenberry's influence/ One comment, there or elsewhere, was that his relationships with women tended to be physical rather than intellectual. However, I get the sense from Majel Barett that she is not an airhead. I also sensed that Rick Berman was a strong influence in later years, and perhaps a bit of an asshole.

Yes, I agree Sisko was a somewhat uneven character (as was Picard, at his worst in any number of season 1-3 episodes, and at his best in "The Inner Light" wherein via a probe's intervention he lives a lifetime as a member of a dying civilization -- I can't imagine ever being the ame after such a wrenching experience). FWIW Avery Brooks appeared ambivalent about playing the role. My wife loved the deep space "Hawk" -- not a person to fsck around with.

"What does this have to do with XP, and how does forllowing XP help or guarantee this dosent happen?"

I was merely stating what Kent Beck has repeatedly offered as the reason behind XP: it's a means of delivering value constantly, so that when a project getes cancelled, at least *something* valuable is in production. Contrast this to the longer development cycles of other approaches.

"Agility dosent depend on a process, it yet again depends on the people working on it."

My suggestion is that a talented team with a good process will have a greater chance of success than a talented team with no process, or a process that is incongruent with reality.

"The argument about waterfall method is so old that you dont even have to talk about it. This was addressed long, long time ago with the introduction of the OOAD."

I have seen countless OO projects planned under a waterfall methodology. Apparently, you're one of the few that thinks it's been discredited. I don't think it has.

"The ideas OOAD talked about is what Extreme Programming stole and re-branded under their name."

I find this curious. Certainly XP evolved out of the OOAD (Smalltalk) community, but to brand that as "stolen" has a connotation that I don't think is reflective of history. Perhaps you could elaborate.

"Sad, sad, sad. Very sad. I thought you were following logic. Lets analyze your sequence of premises and conclusion.

Premise 1: Success depends on hiring good people.
Premise 2: Success depend on a good team.
Premise 3: Totally unrelated argument here... about ideas stolen from other places
Conclusion: XP is special and good."

Perhaps I haven't articulated my position properly, as this isn't exactly what I intended.

Premise 1: Success depends on management support
Premise 2: Success depends on hiring good people
Premise 3: Success depends on good team dynamics
Premise 4: Success depends on an effective process
Premise 5: Processes that promote agility tend to be effective in modern software development.
Premise 6: XP in particular is special because it has a unique (and explicit) value system. It has the courage suggest that the most important thing in a software project is to actually deliver simple software through communication and feedback. This kind of value system is sorely lacking in many projects.

Conclusion: I didn't really come to a conclusion, but a stab at one is: many talented teams with good dynamics and management support have still failed to deliver good software because their process wasn't congruent to their task and their environment. XP can help good teams play to win. If you're not a good team, XP won't help you.

"Feedback is needed in any thing, and courage, what the hell does it have to do with XP?"

All of the core values I listed were values that Kent Beck listed in the earliest days of XP's development in 1998, and they are repeated in the first XP book "XP Explained". They are also listed here.

As for valuing courage, Beck's theory is that all methodology and process is based on fear. To actually focus on delivering software instead of documentation and "cover your ass" politics takes courage. If you haven't had to deal with it, tip of the Stetson to you, you're lucky.

"XP is nothing but some good from common sense that people developed, with a few additions of his own that are so stupid. Fololow the common sense for delopment, and you dont need to call it a process."

If it is such common sense, why is there so much resistence to it? And please don't just say "well there's resistence to the stupid elements", because for someone preporting to be logical, you're certainly inserting a very subjective evaluation into your critique.

It seems that every critic of XP dislikes a different aspect of it. I would suggest that individually, an XP practice may seem common sense. What's not common sense is the discpline involved in the way XP proposes each practice, and the articulation/packaging of all 12 practices into a framework where each practice reinforces the other.

You might find Pair Programming, 40-hour week and continuous integration a little more exciting. I'm not saying that it works or even that you should have heard of it, but a "quick look" is definitely not a good reason for rejecting it.

Personally I find that some of its suggested methods are right on the spot while others a bit on the idealistic side. Still, I would like to try it and see first-hand how it works in a proper business environment.