Xp Boundary Conditions

[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:

Examples include: 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.


EditText of this page (last edited December 12, 2002) or FindPage with title or text search