Maybe XP is "more expensive" than having a crystal ball and doing it "right" from the start. If this is true, then we need to communicate this "price" to the business interests that may consider XP as the way to go. Advocates of XP need to be careful not to mislead or create surprises when promoting XP in an organization. 

XP is often described as a LightWeight methodology. Perhaps this isn't true. Perhaps we can construct an argument that XP is a heavy process. 
----
Obviously, XP seems unarguably light-weight in the following areas:
	* Documentation.
	* UpFrontDesign
	* Communication between developers and customer
	* Change approval
	* (any more?)

However, perhaps we can view XP as heavy weight in some other areas. Keep in mind that there are good reasons to do all of these things, yet they may seem like extra work at first glance, or may turn out to be a lot more work than first thought:
	* Maybe incremental design is more expensive than the mythical ''correct'' up front design. In XP sometimes you build something that works today, then throw it away when something else is needed. Maybe this could be viewed as "wasted" effort. ''You only '''throw away''' the parts that are not needed/refactored.  The rest stays''
		* I don't understand the point of saying it is more expensive than a ''mythical'' alternative.  Isn't that kind of like saying a horse is less valuable than a unicorn?
	* Continual Refactoring. See previous.
	* OnSiteCustomer - That's a huge investment on the part of the customer
	* XP requires a higher level of discipline for everyone, especially the programmers, involved than any other methodology. ''Not more discipline than for ISO900x shops, CMM level 4 shops, and PSP/TSP shops (PersonalSoftwareProcess/TeamSoftwareProcess).''
	* XpPlansMore - Maybe more time is spent in planning over the lifetime of the project  ''More overhead '''time''' is not heavyweight - sure, a StandUpMeeting lasting 15 minutes every day adds up to 62.5 hours per year, while a 1-hour meeting every week is only 50 hours, but how much time does that hour waste, and how much prep time does it require?''
	* Always have a running system. Maybe it requires more work to make additions over the course of time, and keep a system running than to break the system until it has the new stuff.

----

Thoughts?

"Heavy weight" in a methodology doesn't exactly mean cost, as the points above seem to imply.  It tends to mean reliance on cumbersome and somewhat unnatural rules.  A lightweight process is more intuitive.  An intuitive process doesn't necessarily mean lowest implementation cost.  Does methodology "weight" derive from the weight of the manuals used to describe it?

''If the '''Weight''' of a process is determined by weight of the manuals describing it, then XP is getting heavier by the publication. Heck, each book is thin, but there are over half a dozen of them now, plus RefactoringImprovingTheDesignOfExistingCode. <grin>''

Having more written on a subject doesn't make it heavy, does it?  It might if all the reading was prerequisite for practice, but that's not the case.  Where's the real baggage here?

''I'm glad we've moved away from the 'heavyweight' vs. 'lightweight' distinction. JimHighsmith, in AgileSoftwareDevelopmentEcosystems, uses the terms 'agile' vs. 'rigorous'.''

XP may be 'agile' ... but AlistairCockburn points out that it requires an extremely disciplined (and probably small) team. The amount of discipline required to do XP in a sustainable way looks more '''rigorous''' than any other methodology around.
----
I think the point of this page is to explore the costs (obvious or hidden) in XP that are different than other methodologies. What is a better title for the page?

HiddenCostOfXp or XpHiddenCosts
----
''Maybe XP is "more expensive" than '''having a crystal ball''' and doing it "right" from the start.''

Please, may someone tell me where I can acquire a reliable crystal ball? --DaveSmith

''Cute, -- but wrong. There are times when an up-front design is not only correct, it is just what the doctor ordered. Just because your experience doesn't support that doesn't make it not true. This applies to all the stuff (read, BS) up above about "mythical" up front design and horse versus unicorn, etc. I get tired of hearing people tell me that it can't happen when it damn well '''has''' already happened some small number of times in my career.''

OK, ''correct'' up-font design (that's what you meant, right? not just any old up-front design) happened some small number of times in your career. Mine too. But the reason that I prefer XP for day-to-day working is that I can't tell ahead of time when an up-font design is going to ''end up'' being correct, and I don't know how to make an up-front design ''be'' correct when I need it to. If you do know how to do those two things, repeatably, on demand, please share.

''Don't know what to tell you. Don't stick to any one design methodology school over any other, but have had a string of successes in up-front design when it was'' my ''up-front design and when I was brought in'' before ''anything was cast in iron. That doesn't make me the Up-Front Design King; it is just an observation.''

''As far as a design "being" correct -- there are a zillion schools of design out there that have methods for determining if your design is good or not. And please don't talk about a design "ending up" correct -- designs are '''made''' that way or they are made '''to be''' that way. Luck has very little to do with a proper design result.''