BarryBoehm once made a curve showing that correcting an error gets more and more expensive as a project evolved. This insight was reached in the good old WaterFall days, so it goes something like:

An error caught in Design costs 10 times as much as one caught in Requirements.
An error caught in Production costs 10 times as much as one caught in Design.
    ^
 C  |			*
 o  |			*
 s  |			*
 t  |			*
   c|                  * 
 o h|                **
 f a|              **  
   n|           ***  
   g|	    ****
   e|*******
    +----------------------->
     Req Ana Des Imp Tes Pro
----
RonJeffries will soon publish on extremeprogramming.com an article with a discussion of this curve. Won't you, Ron?  

''Yes. It's at http://www.xprogramming.com/xp_magazine.htm. 
 [We're sorry! The page you're looking for cannot be found 20030119]
 [Try a related page: http://www.xprogramming.com/xpmag/cost_of_change.htm instead] 

I'm soliciting articles rebutting Alistair's observations. They should be clear whether they are addressing exactly his measures, or different ones going to the same point.''

And we'll have a little discussion of this at OOPSLA in an informal setting.

''yup''

----
A more accurate statement of the concept would be that an error committed in requirements costs ten (or some number) times as much to fix if caught in design than it would if it were caught in requirements. Are we sure Barry didn't reach this insight in the good old ''Spiral'' days?

-- WaldenMathews

----
After discussion on the mailing list, the view seems to be that while this may be true of XP there are a number of factors that mitigate this.
	* Each user story is very short. This means that the numbers always remain very small. Keeping the duration short keeps exponential effects under control.
	* In 'traditional' development, a requirements change is seen as an error. In XP, it is business as usual.
	* ''(That's scary --- accepting a 10x, 100x or 1000x cost hit is "business as usual"? If it is, I wouldn't go around advertising it.)''
	* The phase boundaries described in the original CoC curve do not exist, or are blurred, in the development of an XP story.
	* ''( possibly "Release to an external test group" and certainly "Release to the field" boundaries still exist, with the similar costs)''
	* Each User story development is isolated and the effects are not cumulative.
	* In XP, an error that reaches production will be fixed by adding the fix to the story queue. It will be treated as another story, limiting its cost. 
	* ''(Not clear how adding a 'bug' as a story reduces the cost of fixing the bug, compared to just reporting it.)''
-- TomAyerst

----

The cost can be much worse than exponential. I lost a point to a YouArentGonnaNeedIt person in that I wanted a framework and they didn't. Everyone did it your own way, and that code went into many releases of many products. Now the day of reckoning has come. The cost of not having a framework has been huge and very disruptive. Thinking ahead would have saved so much time, money, and effort.

''Was this an XP project?''

[It doesn't sound like it. PairProgramming and OnceAndOnlyOnce are supposed to prevent everyone from doing it their own way. In fact, they're supposed to prevent you from having to do it more than once in the first place. The XP way would have been to notice the duplication as soon as it occurred and then (and only then) ReFactor the duplicated code into a framework, one providing no more generality than is necessary to solve the problem.]