In conclusion, kudos to the team for writing such an honest and open appraisal of its experience with XP ”although the conclusion surprised us (our emphasis):
HYPE! | XP, or our evolved version of it, has done wonders for us as a team. [13] |
This is a chilling example of Extremo logic and a shining example of another XP success story on a par with C3. Quite simply, the conclusion isn t borne out by the rest of the case study, which paints a much less rosy picture (although the article s author appears to be blinded to the signs that XP was causing more problems than it was solving). As a project increases in team size , the XP practices become more difficult to adhere to. The main deliverable ”working code ”inevitably suffers as a result. The ATLAS project is evidence that this really is the case.
In the next section, we shift topics slightly to look at the way in which XP handles architectural scalability (as opposed to project scalability).
Projects That Are Very Small
(Sing to the tune of The Wall by Pink Floyd)
We don t need documentation
We don t need no UML
We use our nose for quality assurance
We re sniffing out the code that smells
Hey
People
OMG can go to hell
All in all we just like
Projects that are real small
We don t need written requirements
We don t need project control
We code in pairs in one big-assed room
We never ever code alone
Hey People
We never code alone
All in all we just like
Projects that are real small
We don t need no architecture
It emerges from the code
We unit test, code, and refactor
Don t plan ahead, no, not at all
Hey People
We don t plan ahead at all
All in all we just like
Projects that are real small
We don t need no project deadlines
We refactor every day
Schedule is the customer s problem
They can t replace us anyway
Hey People
They can t replace us anyway
All in all we just like
Projects that are real small
All in all we just like
Projects that are real small
[13] Ibid., p. 6.