[From NoProcess, see also ExtremeDogma (?)]

I don't think that many people would disagree that dogmatic methodologies such as XP and RUP have very limited applicability. No-one would be surprised to see the TechniqueFragments espoused by these methodologies (UML, refactoring etc.) have a much longer life than the methodologies themselves.

The SoftwareDevelopmentPattern folks seem to be on the right track. Rather than proclaiming 'Thou shalt refactor!' they present a technique together with the context in which it is deemed applicable and a couple of snazzy real-world examples where the technique was useful. Patterns and AntiPattern''''''s may do much to remove some of the intolerance and narrow-mindedness methodologists have imposed on software development. But even these are no good replacement for the opportunism and random attacks of ingenuity which mark nearly all successful developments.

Much the same argument (as Costin presents here) was applied by the Philosopher PaulFeyerabend to the methodologies produced by philosophers of science. His book AgainstMethod has a title equally as controversial as that of this page. The altercation following its publication, I imagine, however was less gentlemanly. I can recommend this book to those of you who do a bit of light reading of the train to work. His arguments are based on historical events rather than flimsy analogies and his style makes him easy to follow and fun to read. -- ChrisSteinbach

''I don't think that many people would disagree that dogmatic methodologies such as XP and RUP have very limited applicability.''

Well, I would, on two counts:

First, I don't think XP has "limited applicability".

''I second this. I know that Kent in his book say otherwise, but I suspect he's just being modest. ScalingExtremeProgramming, VirtualPairProgramming and many other pages show how XP can still be used where there initially seemed to be limits.''

''Why does it look like XP applies everywhere? It probably does. The ideas proposed in XP are absolutely fundamental to software construction. Unit testing, refactoring, planning...how could you write software without them?. --js''

I've been involved in dozens of software development efforts, of several different sizes, from telephone switch software to database-backed Web applications to requirements-analysis tools to image-processing programs. I can honestly say that doing XP on any one of them would have improved things.

Might there be areas where XP wouldn't work well, or where some other known process would work better? Sure. But given what I've seen, ''those'' are the areas that are limited.

''I would go further and say those areas are non-existent. At least I cant come up with an example of one. -- js''

Second, I don't think XP is "dogmatic". That implies an arrogant assertion of principles without regard for practical concerns. XP, by contrast, is very empirical: its proponents didn't sit around and think about what would be a good way to develop software - they ''noticed'' some practices that helped them develop software, fit them together in various ways, and tried out the results on real projects. -- GeorgePaci

[I agree, XP is not inherently dogmatic. It may in some or many cases attract people who are dogmatic, and I've seen people that approach it dogmatically, but then it ceases to be XP. In that case they reversed the preference of 'Individuals and interactions over processes and tools.' But XP in and of itself does not require dogmatism. -- DonBranson]

''I also find XP practical/empirical. After all, how can you be dogmatic about practices that are so fundamental to software. You just do them. XP does them simplest way. Go for it!! -- js''

Just curious about sources - Where did the practice they just "noticed" come from? Did they develop out of the blue sky, or did some one think, plan and do them? It seems to me that a process and planning are required here and that chaos and happenstance did not create the "noticed" practices. The fitting them together in various ways and trying out the results on real projects is not a '''NoProcess''' event. It takes skill, thinking, innovation, planning and research and courage to "fit together" the pieces , a mix of the old and the new, into a solution method. I believe that this is a process. It is a moving ahead, progressional thing this thing called process, not the moving of a fixed number of pieces on a game board whose ultimate goal is to "checkmate" an opponent. In the thing call process, the goal is progress toward and the generation of "NewUtility".

''I disagree that individual practices could not materialize as a result of NoProcess. Quite the opposite. NoProcess gives you the freedom to apply your thinking, to innovate and also to recognize, reuse and adapt older practices. I don't know how the XP practices came about. I'm sure, though, that they could not emerge from the strictures of another process without actually abandoning that process.''

''I don't deny that developers work in a less constrained manner than any process would suggest. But what, then, is process? I like to think of it as a work of fiction. It shows you how you might plausibly use the tools on offer to get through a project. The details, characters and problems are cut out of the story, making it pretty drab, but it still has some educational value. Now comes the best bit! Each process has its own bag of tricks which the unscrupulous NoProcess developer can steal from without choosing in favour of any particular ideology. It is he who will stumble across new ideas and more effective modes of working. --ChrisSteinbach''

Some more examples of where XP overcomes it's supposed limitations.

	* LackOfOnSiteCustomer
	* GuiUnitTesting
	* UnitTestingLegacyCode
	* RefactoringFrameworkBasedApplications

That just about covers everything: large scale, frameworks. What else was there. -- js

''I see that my arguments against this conception of ''limitation'' elsewhere on this page must have lacked lucidity. Let me clarify.''

''You exhibit what I will call the TvShopAttitude. The idea is that you show your product at work in seemingly limitless circumstances and then order "Buy it!". To give you a feel for the problem with this attitude, I have an example: ''

''Think of how XP would apply to, say, tooth-brushing. You could do it of course: iterative applications of tooth-paste, collective tooth-brush ownership, automated tooth whiteness testing, why not? However, I couldn't fool you into thinking that XP will be a big player in the tooth-brushing arena. Compared with your normal dental-hygiene procedures, you may agree, XP has serious limitations. ''But you have to make the comparison.

''When you start to compare XP with, for example, JSD, you see that JSD has tools for concurrency, whereas XP is limited in this respect. When you compare XP with CleanroomSoftwareEngineering you get the feeling that XP wastes a whole lot of time on UnitTest''''''ing. Whichever method comes out on top during the comparison, don't forget that ideas can be changed. If you are smart enough, you may be able to make the weaker argument the stronger. JSD could be combined with elements of OO. CleanRoom might look better with a dash of RAD. -- ChrisSteinbach''

----

''Second, I don't think XP is "dogmatic"...''

XP is very dogmatic. You have to stick by all the practices, which reinforce each other, or otherwise you're not doing XP. In contrast, RUP allows all kinds of customizations (comes close to everything for everyone), and you can even have a consultant/methodologist in customizing RUP for you -- not that it would help or anything, but in theory it should. -- CostinCozianu

''Aren't you confusing "being dogmatic" and "showing integrity" ? Or "allowing customizations" and "targeting anyone with some money to spend" ?''

XP is very pragmatic. XP is a "minimal process", "the least we can do and still produce great software". You have to stick by all the practices, which reinforce each other, or otherwise you're not likely to be able to produce great software, unless you add other practices to compensate. -- KeithRay

----

Well, a dogma is a set of immutable principles and beliefs that one should abide. Dogmatic means you don't get outside of the set of rules constituting the dogma. Definitely the customization story is for people with money to spend, but nevertheless, it means that they are less dogmatic. Certainly the customizations will have to fit into a weaker dogma, so I still believe RUP is dogmatic also. -- CostinCozianu

Not that I lack faith in Costin as a lexicographer, but:

From http://dictionary.com : (the AHD; follow the link for other dictionaries)

 dog�ma n.

	1. A doctrine or a corpus of doctrines relating to matters such as morality and faith, set forth in an authoritative manner by a church.

	2. An authoritative principle, belief, or statement of ideas or opinion, especially one considered to be absolutely true. See Synonyms at doctrine. 
	3. A principle or belief or a group of them: "The dogmas of the quiet past are inadequate to the stormy present" (Abraham Lincoln).

We can't possibly be talking about sense 1, since the ThreeExtremos haven't even applied for tax-exempt status as a religious organization. Sense 3 probably isn't it, either, since it's pretty broad: just having some principles or beliefs associated with XP doesn't say much about it. Sense 2 kind of fits, since the XP spokesmodels make authoritative statements and structure things in terms of values and principles -- but they don't seem to consider any of them absolutely true.

 dog�mat�ic adj. 

	1. Relating to, characteristic of, or resulting from dogma. 
	2. Characterized by an authoritative, arrogant assertion of unproved or unprovable principles. See Synonyms at dictatorial.

Well, if we pick sense 1, and link it to sense 2 of dogma, then yes, XP is dogmatic in that sense. This has the same problem as sense 3 of dogma, though: it doesn't say very much - just that XP is related to some authoritative statements about XP made by the people who developed XP. In fact, I'd go so far as to say I've ''never'' seen dogmatic used in sense 1, about anything.

I think we're really talking about sense 2 (as I indicated above) - the pejorative sense. What would it take for that sense to apply? Well, the utility of XP isn't unprovable, so it'd have to be unproved. In addition, Ron and Kent and Ward would have to get personality transplants so that they could arrogantly assert XP's principles, instead of the humble explanations they offer now.

Note that the Extremos have a totally free hand to set the ''definition'' of XP and claim that that's absolutely true -- but that's not dogma or being dogmatic, that's defining your terms. The claims that have to be unproved or overstated are claims about XPs ''usefulness'' or ''utility''.

The criticism of XP as being "dogmatic" either uses the catch-all senses of the terms (which is fine, but kind of uninformative and, considering how "dogmatic" is usually used, misleading), or needs to be backed up with some facts, in which case we're just back to the question of how well-proven XP's utility is in actual use.

So if you're tempted to say that XP is dogmatic, maybe you should just cut right to the chase and say it's ''unproven''. (I disagree, but at least your interlocutors won't have to take this detour again.) -- GeorgePaci

''Hey, I wasn't criticizing XP for being dogmatic. It was ChrisSteinbach, and I tend to agree to his position that XP is dogmatic - without judging the value of that. Since I haven't practised XP, maybe I'm wrong, it just looks to me that way. I'm still undecided if dogmas are necessarily bad in any circumstances, just that I feel more comfortable without them. -- Costin''

''A little knowledge is a dangerous thing, and a little dogma might be a helpful thing...''

----

Dogma is more like ''authoritative opinion'' than ''immutable principle'', but for the purpose of this discussion that may not matter. What does matter is that XP dogma is for its own sake, not yours. In other words, no-one proposes that XP is the only way to develop software. Rather, they propose that to know whether you are succeeding or failing at XP, at least make sure it's XP. If that's dogma, then all scientific method is dogma, in the sense that you need a control if you are going to draw a conclusion. Zeal, yes. Dogma, not really.

''The scientific method is a philosophy built through rigorous logic in order to determine facts. That's as much dogma as 1+1=2 is dogma. While you may argue that indeed 1+1=2 is dogma, that would be pretty ridiculous. As always, XP is a methodology sold by consultants. Your choice as a critical thinker, responsible for the hundreds of thousands of dollars budgeted to you is whether you accept the experiment. Personally, I enjoy experimenting with process to find out what works and what doesn't. If you feel comfortable testing XP, then do so, and do so honestly or else you're just wasting all that time and money to learn nothing. -- SunirShah''

If you have a theory, like "if you use XP on a project like this, you will succeed", how do you go about proving its truth or falsity? Does your method of proof involve some kind of stability in the definition of XP and its formulation in your experiments? Is insistence on that stability a form of dogma, or is it part of scientific method? Or is it perhaps both? Please don't be distracted by the fact that these are imprecise measures and imprecise proof.

''I don't think I'm making my objection very clear. The ScientificMethod is not the same as the application of the ScientificMethod. The ScientificMethod isn't dogmatic as it is (intended to be) a logical system designed to find the truth, even to the detriment of existing beliefs. It is very anti-dogmatic. The proposition here is that XP is dogmatic, and that's because XP rejects the application of the ScientificMethod to itself. It may be pragmatic, it may be panned out in experience, but it's still dogmatic because it isn't demonstrated rigorously. It's possibly for the reasons you suggest--that designing an experiment is difficult--but to the cynical observer (the audience of this page) XP is just another canned methodology being sold to you. I also don't think that designing ''valid'' XP-related experiments will be too difficult once a sizeable sample population exists, but that's another concern. -- SunirShah''

"...XP rejects the application of the ScientificMethod to itself." This statement needs some explanation, I think. It means that if you were to attempt experiments to prove XP's utility, the rules of XP would prohibit that. Truer is that XP does not contain its own proof, but who would expect it to?

The distinction of interest here is between DisciplineAndDogma, the degree to which you will allow something integrity and a chance to demonstrate itself before you dismantle or dismiss it, versus the degree to which you will hold onto a doomed notion in the face of basketloads of evidence to the contrary. The latter is dogma; the former discipline. A different page would explore the relationship between these two.

The flaw in this page is similar to the one on WeTriedXpAndItFailed, in that XP can't be dogmatic (it could, by in effect saying: There can be none other, but it doesn't), but its users or would-be users can. And to the extent that people here preach the wonders of XP without having used it, I would say that resembles dogma more than discipline by a long shot. ~~ WaldenMathews

I say that XP rejects the ScientificMethod because people asked them to do it, and they (*) rejected it outright and vehemently. The reasons they did this are their own, but the fact remains they are not going to spend their time attempting to justify it through studies.

Not to say that this is unusual. Most (i.e. all) methodologies do this, preferring to let academia pick up the tab of studying it. After all, there's very little point when methodology is essentially religion: you have to convince people's faith, not their minds. Then again, handwaving leads to people accusing it's just snake oil. I guess it's a matter of cost effectiveness. Studies are expensive, and have low impact in the marketplace, and it needs to be said (to be fair) that the consultants make more money by preaching than proving too.

Maybe one day I'll be a methodologist too. It's a good way to retire. ;)

(*) The meaning of ''they'' is very important for ''this'' discussion. Extreme Programming isn't trademarked (no really, it isn't--I'm not sure why). But the methodology called ''XP'' is effectively owned by the ThreeExtremos. If ''you'' claimed that XP allowed, say, the use of an AutomatedTestTool instead of UnitTest''''''s, you are not likely to succeed in the face of KentBeck who claims otherwise. Does this address the concern you raised in your last paragraph? Would-be users don't have a say. Only ''they'' do. -- SunirShah

''I have not claimed the above, but I would like to better understand the distinction being made. -- KentBeck''

	 :	Sure, I was just trying to make a believable example of what would constitute a claim by users vs. a claim by the creators. I don't recall you saying anything specific about not writing UnitTest''''''s in lieu of using, say, RationalPurify alone, and I never intended to put words in your mouth regarding that. 

	 :	The distinction is simple, though. The public looks to TheThreeExtremos to describe XP. They do not look at any random person, such as Walden or GradyBooch or myself, because we do not play the role as the Definer of XP. Thus, the point that users can make XP what they want is wrong, because they can't. Sure, they can dilute your trademark--and since you haven't registered it, you can't stop them-- but dilution is not the same thing as definition. In fact, it's the opposite process. -- SunirShah

Okay, I understand your point now, and I ask that you consider the distinction between XP and the ''they'' that you deem to own it. That distinction matters because while ''they'' may refuse to spend their time justifying XP with studies, that doesn't prohibit anyone so inclined from doing so, including you if you feel it's a worthwhile pursuit. ''They'' may be dogmatic in their opinion as to the value of studies, but that's beside the point. ~~WaldenMathews

The problem with the lack of prohibition is that each study in software methodology is bogus with probability near 1. They're all biased in favour of you buying something from them, whether it be services, lessons, or a consultancy. Are you really going to listen to the StandishGroup's study re: software failure? If I did a study regarding XP, I would be inclined to bias it in favour of eliminating WaterFall and suggesting XP wasn't adaptive enough. Would you really trust ''my'' opinion? Maybe, if you worked with me, you might. What about DougRosenberg? -- SunirShah

There's no way to guarantee an unbiased study or experiment, but there's disclosure of the methods and information used, and there's review. This is not a problem peculiar to software methodology, either. Using language well, it's a stretch to think of a method or discipline as "dogmatic", but if it contained words to the effect of "do not question me" or "accept no other", then I think it would be reasonable to call it "dogmatic". Do you know of any instances of this in the XP literature?

~~ WaldenMathews

----

XP is dogmatic? TheyreJustRules. http://www.xprogramming.com/Practices/justrule.htm

----

Where is this discussion leading I wonder? When I chose the word 'dogmatic', although I knew it was a juicy one, I didn't expect that the Wiki populace would linger on it. Nevertheless, it does suggest a certain negativity and that at least
demands an explanation.

The subject of silver bullets often comes up for discussion. When it does you will notice that all and sundry are agreed that these silver bullet chaps are highly elusive and not to be taken seriously. The tone of the discussion surrounding XP however makes me believe that this disapproval of silver bullets is, in reality, only half-hearted.

Much intellectual effort is expended in exploring and supporting the use of XP in new and unchartered situations. This in itself I can't object to. What I find repugnant is the absence of any techniques (old or new) from these discussions which do not have the XP stamp of approval.

The history of software development has provided us with a rich array of tools: formal specification languages, tools for prototyping, data analysis, cost and risk estimation to name but a few. Without reference to these techniques the question does not become 'How does XP compare to other modes of working in this situation?', but rather 'Can we find some abstract arguments that would make XP work in this situation?'. Since we're all bulging with brains here, we invariably find such arguments.

Anyone who watches too many action films may know the feeling. No matter how sticky the situation, the hero always pulls through. If you don't sympathize to any great extent with the hero, you start to feel a trifle exasperated. Knowing as you do that he will be with you through to the very last scene. This, in essence, is how I'm beginning to feel about XP. A page starts off discussing an area that at first seems highly problematic from an XP standpoint. However, scroll down a little and lo! The problems are resolved and agreement is reached that XP was the man for the job after all.

By introducing the Patterns motif (see above) I was hoping to show the way ahead, you might say. It was this, if anything, I hoped you folks would latch on to. No matter; Alistair has his TechniqueFragments which may yet prove to be a hit. -- ChrisSteinbach

----

I'm still puzzled as to why one would call XP dogmatic. Are there some XpPolice floating around that are passing judgement?

There are certainly ''aspects'' of XP that I would call dogmatic. The main one is that when someone cries "WeTriedXpAndItFailed", the first question that is asked is "Did you do AllOfXp?". That's a defensive reaction that's been learnt, IMHO.

The second dogmatic aspect about it is that XP encourages people to try it by the book, to begin with.

However, the fundamental truth about XP is that it encourages customization. People are told in the XP books that they should customize the process to suit themselves, ''once they've experienced the book process''. Indeed, a claim can be made that if you're still doing XP by the book after a year, then you're not doing XP. -- RobertWatkins

''Well, your first example sounds more like an individual being dogmatic, not the process. When things go bad, people just fall back on what they know, which often is riddled with bad habits. XP principles are like etudes to be practiced and applied in real world situations, not observed and consciously adhered to.''

''I thought Jazz was dogmatic because my guitar teacher repeatedly made me play scales up and down the neck through a variety of wicked keys. It wasn't until later that I realized I was learning the fundamental skills needed to approach Jazz is being fun, free, and open.'' 

''So, it wasn't Jazz that was dogmatic... it was the way the fundamentals were taught to me that felt dogmatic. I'd likewise posit that XP is not dogmatic, but the rigor of initially learning some of the principles might feel dogmatic.'' 

''When you're done literally practicing an XP principle, just go back to what feels natural. Over time the principles that work will start to emerge within your own style. -- MichaelLeach''

----

The simplest test to prove whether XP is dogmatic or not is to see how far can one go off the letter of the book, without being reproached YouWerentDoingXp. To invoke TheyreJustRules is demagogic -- of course one can skip as many rules as he likes, but then he's not doing XP, what rules exactly can you dismiss?

	* Can you do BigDesignUpFront?
	* Can you skip UnitTest''''''s?
	* Can you do serious requirements engineering without listening to one story at a time?
	* Can you program alone?
	* Can you apply a formal design method, and forget to listen to the code and RefactorMercilessly?
	* Can you choose not the simplest thing at a time?

There are lots of situation where one can find stringent reasons to do any of these, and/or many other things not within the ExtremeProgrammingExplained letter and spirit. I'm sure you can do any of these and maybe all , but then you're not doing XP. So XP gurus require from you to abide by their dogma. It might be a wonderful dogma and it might apply everywhere successfully, but it is a dogma nevertheless. And exactly like a dogma you are required to abide to it by faith, as Sunir pointed out.

I think ChrisSteinbach is right, no matter what the situations is the XP gurus will tell you that XP solves them all. After all KentBeck told us "That's all there is to software". If you go to the Catholic church they will tell you that Catholic dogma is all there is to the salvation of soul. Or is it? -- Costin

-----

Another analogy with religious dogmas is is the fuzziness surrounding it roots, the ChryslerComprehensiveCompensation project. Apparently it was either a failure, or a partial success, but no-one's really sure. There are discussion on wiki on what lead to that, but in all of them XP is above any suspicion. Maybe the failure was outside XP core engineering practices, but then XP failed as a method because it didn't address those issues. The bottom line is that the customer considered it a failure.

But no unbiased record on what was the complexity of the problem and the quality of the solution provided by the XP team. Maybe something like FPA, complexity of the solution using OO code metrics, performance, cost/benefit evaluation would be helpful. After all, why trust a process that failed at its very beginnings. If we are to follow a dogma, why wouldn't we follow MicrosoftProcess instead? After all we can pretty much see its successes for ourselves.

''That last point is confusing. Are you being sarcastic or honest in your suggestion to follow Microsoft? They put a lot of effort into developing, describing, and publishing their process, and they are one of the most mature software companies in the industry (~~CMM), and many people spend a lot of effort emulating it, and they're profitable in doing this. On the other hand, many aesthetes (for lack of a better word) don't like the quality of the output. Could you clarify what you intended?''

I'm being both sarcastic and honest. The quality of MS products is entirely another topic, but they have both very buggy products and top quality products. The bottom line is that overall a majority of their projects complete successfully, both businesswise and from a technical point of view. I'm a NoProcess guy, so I wouldn't follow any dogma -- be it XP or Microsoft. But if I was to follow one, what's the objective argument in favor of XP?

----

I think XpIsDogmatic, and I just don't care. In fact, I think it's a GoodThing. I don't think XP would have gotten as far as it has without being dogmatic about its principles. 10 years from now, I expect that XP will lose the dogma, but right now it needs it to grow. -- RobHarwood

I agree to some extent. KentBeck and his merry men have introduced some invaluable ideas and people should become aware of them. They, more than anyone have the right to argue, dogmatically or otherwise, in favour of XP. I only become uneasy when I see a general trend in this direction.

Those who disliked my use of the word 'dogmatic' had some interesting things to say. I think some people understood that I was setting TheThreeExtremos up as figures of authority. Not really. I recognize that XP has been a collaborative effort and it is best left that way.

Some felt that XP could be dogmatic only if that was explicit in some sort of authoritative account. Someone else defended XP by saying its principles are ''absolutely fundamental'' to software development. Odd. Very odd.

The position that XpIsDogmatic is, however, difficult to defend. I would therefore prefer to give it up, rather than labour the point. "So what was your problem?" I hear you say. Well, I just don't want us to be so enamoured of a progressive idea that the idea itself becomes a barrier to progress. We already mentioned some ways to prevent this. Calling these ideas dogmatic, I imagine, isn't one of them. -- ChrisSteinbach

''Except that ideas can't be dogmatic. Ideas are just ideas. A fullish and unconditional belief and submission to a set of ideas is definitely dogmatic.''

''XpIsDogmatic, because Xp is a discipline consisting of an inflexible submission to a set of ideas. There might be situations where ideas just don't apply or are not the best, yet some "XP believers" think that they are so "absolutely fundamental" (I love this word) to software development that they should be applied everywhere. So we witness that Xp created such a hype that XpPractice is by and large dogmatic.''

''As to who speaks for XP, we can see plenty of differences, RonJeffries has positioned himself "we don't think it's the only way, but it worked for us, and if you give it a try it might work for you", which is the most non-dogmatic statement and I admire him for that. On the other hand, KentBeck takes a dogmatic position: "that's all there is to software". So here you have it, no wonder why some people believe that XP is "absolutely fundamental".'' 

''Now the real very hard question is whether XP as dogma is a bad thing. At an individual level, it is definitely not, but XP starts applying for groups of two people and more. Then we might hit some problems. The same "absolutely fundamental" problems that we hit with Rational dogmas, by the way.'' -- Costin

So, you can now omit XP from the discussion altogether and focus on the deeper issue, which is the relationship of discipline to dogma. You can define "dogma" as ''harmfully'' holding to current ways, and "discipline" as ''beneficially'' holding to current ways, then explore the fine line at which one becomes the other, and why. That's what DisciplineAndDogma was supposed to be. Sigh. -- WaldenMathews

----
CategoryExtremeProgrammingDiscussion