There seems to be some dispute over 'real' and 'pseudo' methodologies, which points to some confusion over what the term means. While most programmers, SEs, etc. seem to have any ''idea'' of what it means, there doesn't seem to be any solid definition. What do you think a methodology should be? Does the term mean anything, or is it just a smoke-and-mirrors game used to wrap programming in a cloak of mystery? -- JayOsako

----

Does it have to have complex diagrams to be called a methodology?
...or is it sufficient just to have expensive consultants charging outlandish rates to explain it to you?
;->

No, a methodology need only provide useful guidance likely to make your projects more successful.
(...when used in an appropriate context, and managed reasonably.)
-- JeffGrigg

----

Methodology is a point of departure, a framework within which to start a dialogue. It is not a roadmap or an agenda or a menu of anything but a set of rather obvious possibilities. It's like a movable context within which one might try on some notions. The great danger in using a methodology is that it, because it resembles a roadmap and an agenda and a menu, that is will be used as if it were one, when it most certainly is not. A methodology is a shareable context within which to start the dialogue.

Because each instance is unique, specific meaning must be made in order for the undertaking to make sense in this context. The dialogue is about how this situation seems in this context. I received a note from a student this week, asking how PRINCE might be usefully applied to help a company reach its goals. The short form of my reply said if they diverge from the methodology, they are more likely to succeed than if they stick to it religiously.

One of the most dangerous and (evil) things ever injected into the project world is the notion of process maturity. Process maturity is for replicable manufacturing contexts. Projects are one-time shots. Replicability is never the primary issue on one-time shots. More evil than good has come from the notion that we should "stick to the methodology." This is a recipe for non-adaptive death. I'd rather die by commission... [1] DavidSchmaltz

''I don't think all methods are "a point of departure," Some methods are fairly flexible/open (eg. BoochMethod, ExtremeProgramming and the CatalysisMethodology) whereas some are very prescriptive. The ShlaerMellorMethod for example is extremely prescriptive: rules determine which attributes and relationships are allowed - departure from these rules may lead to unbuildable systems since they "translate" their models into code.'' --

----
Interesting, I should have thought this question would have been answered by now, but I couldn't find it up here.
	* CategoryMethodology is the obvious starting point, and lists ''pages containing "CategoryMethodology" in their content'',
	* MethodOrMethodology gives the dictionary definition : ""Methodology" is a series of related methods or techniques, or a system of principles, practices and procedures", which is a good starting place for anyone. 
	* SoftwareMethodology says about the same
	* JeffGriggMethodology I found instructive as an example. ''[Why, thank you! -- JeffGrigg]''
	* I like PoemsAboutMethodology as a tongue-in-cheek.
	* My short answer is, "Methodology" is everything you do to get software out the door repeatedly. The discussion starts there. The answer may or may not have anything to do with diagrams.
	* My long answer is in MethodologySpace. 
-- AlistairCockburn

----
Obviously, XP works for some people, and not for others, like most things. The real question is, ''is ExtremeProgramming itself really a methodology, or just a stylistic preference that you want to justify?''

Or perhaps an even better one is, WhatIfAnythingIsaMethodology, and how does one tell a Real Methodology on from a Pseudo Methodology? Is there a hard and fast definition, or is it a vague, heuristic term, like so many others in this field? -- JayOsako