When something goes wrong on an Extreme Project, you tend to find out right away. After all, if everything is getting done on time, and the tests all run correctly, and no one knows of any problems, you might be in good shape.
When something does go awry (and it will), an ExtremeProgrammingMaster will look at the situation, and with her team, try to make things simpler so as to make them better. Her first step would be to improve the code:
Then, and only then, would she look to human-based improvements. She would examine first improvements that didn't give people more to do.
ExtremeProgramming provides many forms of feedback to observe project quality. Test results, task tracking, commitment schedule, and open human communication are some of these.
You've read about XP. You think it's great. Then you read about the RUP. You think that's great too. Then you read how CarHoare believes the most important thing is to prove correctness. Maybe you think that's great too. Same about reviews, DesignByContract, UI prototypes, Change Management etc.
Cant't we add some or all of these to XP and make it even better? I don't know, but I believe one thing is extremely important:
If you do, make sure you don't break the feedback loop.
Don't replace RelentlessTesting with correctness proofs, but add the proofs if you must. Don't replace ContinuousIntegration with cumbersome change management. Add another layer (*at a different timescale*) of configuration management if you must.
The experience of those doing XP makes them feel that usually you don't need the extra complications. The benefits don't justify the costs.
-- Martijn Meijering
What might be valid reasons for adding complexity?
Correctness can be so important that it is worth the cost of reviews, design by contract or even correctness proofs. If you're writing software for a nuclear reactor or a jet liner or a space probe you should probably do more than just RelentlessTesting.
ExtremeProgrammingChallengeFourteen displays some simple[?] concurrent code containing a defect. So far none of the Extreme folks have been able to build a test that displays the defect.
[add your reasons here]
This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006