Extreme Programming Challenge Fifteen

What about when what your stakeholders want turns out to be flatly impossible? There's no successful way to iterate toward something impossible. Russell and Whitehead spent decades working toward their PrincipiaMathematica?, but if they'd just sat down and spent a year or two planning first, they surely would have found Goedel's results and realized the whole enterprise was doomed. In short, what if XP makes you bark up the wrong tree?

It is not at all likely that Russell and Whitehead would have produced Goedel's results. They were not open to the possibility.

The enterprise was far from doomed. PrincipiaMathematica? is still a marvelous treatise of what mathematics was. Great "business value" was created, even if the complete vision was not fulfilled.

If you can identify a risk, WorstThingsFirst requires you to reduce it or learn that you can't. If you don't think of a risk, you're pretty much screwed using any methodology, but those that eliminate risk early will leave you less screwed. (A fine distinction unless you are a venture capitalist.)

Most software is developed not to fulfill some amazing world-changing result, but to solve some problem that is eminently solvable. Most software projects don't fail for technical reasons but for reasons of mismatch between expectations and reality, both of which could have been made reasonable, could have been made to match, through knowing better what could be done at what cost. A process that enables developers to say how long things will take, and that allows customer and manager to select what will be done in value order, is less likely to founder because of this mismatch.

The projects that do fail for technical reasons usually fail not because the problem was inherently unsolvable ala Goedel, but because the team couldn't find the solution, or the solution couldn't fit owing to the system having become too rigid to accept it. A process that brings risk forward and keeps the software flexible is less likely to founder for technical reasons.

Goedel wasn't working on Russell's program, he was working on Hilbert's program. Russell's Pricipia Matematica was not aimed at showing that all true propositions could be automatically proved with adequate automation. He wanted to show it is possible to derive the body of logic and mathematics from an absurdly small number of assumptions - and he did. Hilbert wanted the automated proof system, and Goedel showed, among other things, any system as expressible as Russell's would not admit of an automated proof system. Where Russell failed in his own program is that he discovered that, as he went to more fundamental assumptions, the more shaky was their definitions and decriptions. That is quite a different story than Challenge 15.

XP starts with, the simplest thing that could possibly work. If that doesn't work, then I suppose an XP-ite would try the next simplest thing that could possibly work. At some point, the XPer would stand up and say, "We can't find anything that will possibly work." And then there would be an interesting and relevant discussion. My guess on the above, IMHO and all that, of course --AlistairCockburn

Am I mistaken or if your stakeholder is asking for something impossible somebody still have to write the recipe test. If a recipe test can be written, the programmer can use the test to generate a solution : - He write a program that give any result - If the test fails he tries again - It may be very long, bug eventually the test will succeed

Provided the test can be written and the test can succeed...

It does remind me of the NP problem where testing for a solution is easy but finding it is quite longer. ---

See ExtremeProgrammingChallenge