[''Note:'' This page uses "boundary conditions" in the physics sense, where different conditions apply at the boundaries of a physical object.  Another page, ExtremeProgrammingBoundaryConditions, uses "boundary conditions" in the topological sense, where a set is described by the ranges of its elements' properties (in this case, the set of projects for which XP is suitable).  Better names for this and/or the other page are welcomed (please suggest here or leave bread crumbs)]

Maybe this page could be renamed something like XpProjectsInteractingWithNonXpProjects?
-----

After reading DavesRealExampleWhereThinkingAheadWouldHaveHelped, I think the general issue arises when artifacts created by an XP team must interface with artifacts and/or environments with different characteristics.  "Different characteristics" might mean:
	* A different rate of change
	* A different methodology
	* Different ownership/management authority
	* Different costs associated with change
	* Formal or informal "freezing" of changes, e.g. publicly released commercial software

Examples include:
	* Enlisting a separate database group to establish persistent object storage
	* Allowing/encouraging enterprise-wide use of business object interfaces
	* Allowing/encouraging local application development on top of common (XP-developed) framework
	* Selling shrink-wrapped software that must coexist with past and future versions

Ordinarily, software is quite malleable, but there are these situations, where the software interface (in the broadest sense) cannot easily change.  It seems that XP relies on the ease of change (see SoftwareVsBuildings).

What are the techniques or patterns that help buffer between the XP artifacts and those other artifacts?

--JeffMantei 2000-12-04
----
'''Question:''' Re: "Selling shrink-wrapped software that must coexist with past and future versions" -- Why is this a problem? If you had sufficient UnitTest's, and a rule never to change a running test, what would go wrong?

'''Answer:'''
One may lock into a suboptimal solution when releasing software.  For example, there may be something in the file format that creates an unfortunate constraint (mentioned on the Dave's Real Example... page above) Yes, you can document this lock-in with tests, but it doesn't help you avoid the problem.