The one true faith is how they consistently come across. --AnonymousPoster?
Many successful projects have been done under almost every known methodology. Many of the methodologies are believed to produce repeatedly good results by those who know them better than I do. There is no reason to believe that there is only one way to do successful software development. There is some reason to believe that one methodology might be preferred over another, and this is almost surely a function of what kind of project is being contemplated. If I've said otherwise anywhere, I was going up on my lines. Point out the spot and I'll moderate it.
I've been assuming that the spirited discussions that XP seems to cause are due to people who are sincerely interested in understanding what we do, how it might work, and whether it is applicable to their lives in some way.
Accordingly, when someone says "but you say you do someRuleX, and if you do someRuleX, then badThingY would happen", I try to explain why:
We're not trying to stifle debate. We're not even trying to debate. We're trying to say clearly what we do and how it seems to work. Thanks, sincerely, for all your help. See also ExtremeProgrammingSystem.
YouArentGonnaNeedIt is "only build it if you NEED it". Well to me at least, deciding that I might need it for X (Rev 2, customer X) *implies* need. Where my judgment comes into play is deciding if this is a *need* or a cool to have.
Building framework or adding stubs for a DEFINITE later use is permitted in YouArentGonnaNeedIt. What it proscribes is frivolous or non well thought out feature.
In my designing training background we make LOTS of decisions on "Will feature X enhance or detract from the learning objectives." To me YouArentGonnaNeedIt is the programmer version of this. - AdamHill
I think I would amend that to say "only build it if you NEED it RIGHT NOW". --BradAppleton
Correct, Brad. YouArentGonnaNeedIt means "only build it if you need it right now". We don't apply judgment: if our current task can succeed without a thing, we don't build the thing.
I express myself regarding XP with the strength I do because otherwise people say, "Oh, I already do that," when in fact they don't. Even so, I had a project manager explain that his project was extreme when every single decision I've seen was the opposite of what I would suggest.
Re: YouArentGonnaNeedIt. I really do mean that if you have two test cases you implement them absolutely one at a time. Take one (the worst one, naturally) and implement the least system you can. Then add the second one. When I do this, I discover hidden simplicity that I didn't know before. That's really my answer to DaveCleal- I would work as he suggests if I thought I already knew how simple the software could be. I don't.
--KentBeck
I think many of the XP pages do a good job of explaining how the whole path is greater than the mere sum of its steps, but could often do a better job of exposing the potential concerns along each step (when looking at the small picture) that get balanced by the whole (when looking at the bigger picture). --BradAppleton
I'll have to think further on this. --RonJeffries
A while back someone asked the question: what is extreme in ExtremeProgramming? Seen from one angle, XP is a very conservative, cautious discipline.. two people are holding each other's hands when they change things.. they test the hell out of things.. they do only and precisely what the business says they need. On the other hand, you find people who have programmed the XP way, or sense its internal logic, saying some pretty bold and direct things. One point of view is that the latter is an aspect of cultishness, and I'm sure than many people see XP that way; but I really don't think that is the reason. I think it is because XP does a tremendous job of facing fear and confronting it so directly that it dissolves. The result is a sense of liberation.
Imagine yourself using the practices. You do not have to decide what features to implement, your users tell you. You are building a solid base of experience in estimating, so you can tell them how long each will take. You always know the status of your code, it is never broken. There is never an integration hell. Everyone on the project knows all of the system because you pair off and tackle different parts of the system on different tasks. If things get complicated, you take time to make them simpler, but they do not get too complicated because you always favor simple solutions. If someone finds some code that is not being used, they rip it out so that you do not have to trip over it time and time again. Now really, what do you have to fear if all these things hold?
Why is XP extreme? Because it takes things that people know to be good in development and takes them to the extreme. Testing is good? Test the hell out of it. Frequent builds are good? Okay, do them several times a day rather than once a week. An iterative, incremental process is good? Put your money where your mouth is and push your increments down the the sub-hour level. Code inspection is good? Okay, have an inspector looking over your shoulder all the time. Simpler is better, make it so simple that it will fall on the floor if you take away a line of code. XP takes practices that the software development community knows to be good to the extreme. Sure, it sounds strident, but the extremity is important; it is the issue..
Frankly I was, for a while, just as put off as many other people. It is like religion in some sense. I remember reading an interview with someone who spent most of his life trying to reconcile spiritual life with science. One thing that he said about meditation really stuck with me. He said many people in the scientific community don't want to believe that meditation is effective in the way that many spiritualists do, but it is an experiment that is available to all of us. Each of us can try it and learn for ourselves.
XP is not as easy an experiment to set up. It requires an extraordinary degree of cooperation and egolessness among it's participants. I see the writings on XP as a recipe book. We can go over and over whether we can skip one ingredient or another, and we may want to take the chance, but if you want a good cake, you use exactly the ingredients the recipe authors used and your chances of success are increased. The authors may not know why each ingredient is necessary, or they may know and not be able to articulate the sensitive dependencies among them. Perhaps over time the answers will be known or clarified, but seen this way it is easy to see why the chefs are so adamant.
Extreme Programming was coined by KentBeck.