NAXPP

Folks come up with all sorts of objections to XP which are not solved by any software process. It is reasonable (but not always helpful) to begin discussion of such objections with NAXPP, then talk about what XP does about it.

Examples:
	* The GoldOwner is not motivated to fund development of a system that would satisfy the GoalDonor.
	* The GoldOwner is funding development "on spec" and does not have a clear idea of who the ultimate GoalDonor might be or what they might want.  Developers and management collaborate in guessing what GoalDonor''''''s might want.
	* The GoalDonor is not willing to articulate their desires in the form of short UserStories about how they wish to use the finished product.  Or they are not willing to accept the developers' schedule and cost estimates for completing software that will satisfy the stories.  Or they are not willing to prioritize their desires and then blame the developers for not having satisfied their desires in priority.
	* Developers are not competent to learn how to work in XP style.  Or they are competent but have no training or information about how XP works.  Or they understand XP but would prefer to continue CowboyCoding as it provides a greater degree of personal satisfaction to them currently.

----
''Developers are not competent to learn how to work in XP style''

If this is a common situation, it might be considered an XP adoption problem.
----
''I have a fabulous new development process known as '''MNM''' - Make No Mistakes.  Your developers refuse to adopt it?  They continue to make mistakes?  They're incompetent or they simply refuse to adopt my process.''

I contend that it's silly to attempt to objectively segregate XP problems from Not XP problems.  Any problem attributed to XP is, in fact, an XP problem, at least in the perception of someone.  What is important is how to address that perceived problem, not simply to label it NotAnXpProblem. -- MarkAddleman

For example, people ask how to get totally accurate up-front estimates for a project. This is NAXPP. No process gives you decent up-front estimates for a project. Once we agree on that, we can discuss how an XP-style team will do its best to give accurate up-front estimates for a project. Until we notice that up-front project estimates are NAXPP, we might consider an XP team's inability to deliver accurate up-front project estimates to be a black mark for XP. That is, NAXPP is not an attempt to duck questions, but put them in context. -- KentBeck

----

This page and DesertIslandFallacy and TuringComplete seem to be dealing with a common way of incorrectly understanding something, and the common response:
* Thing X has problem Y. The incorrect conclusion is that: Therefore, Thing X is bad. Don't use it.
Sometimes the correct response is
* Yes, but every alternative '''also''' has problem Y. Since we're going to have to live with Y no matter which we pick.
or
* Yes, but alternatives that "fix" that problem have the worse problem Z. So Thing X is the best of a bad lot. "Democracy is the worst form of government -- except for all the others." -- WinstonChurchill

Is there a name for this more general fallacy ?

----
See also: XpDoesntCoverThat