Summary

In this chapter we outlined our basic objections to Extreme Programming as a software development process. We also described why XP is unsuited to the vast majority of software projects.

The problem is twofold:

• XP is too rigid; its component parts are too interdependent. This makes XP a very difficult process to adhere to throughout a project.

• When it comes to tailoring a process to local conditions in an organization, or for a particular type of project, XP gets it exactly reversed . The adaptable part of XP is the logical process, which should be prescribed; the fixed, prescriptive part of XP is its organizational practices, which need to be more easily adaptable than they are.

Despite first appearances , XP is not a jacket made for comfort . It is not a one- size -fits-all stretchy glove that does the job of keeping your hand warm. It is an intricate mechanism of moving parts, each part fragile, but somehow kept together by a complex interplay of forces. All it takes is failure at a single joint, a light hammer blow from outside, and the pieces unravel.

No doubt XP can be a thing of beauty when it works, but it doesn t seem made for this rough-and-tumble world, this world of change. And that s the funny thing ”the Extremos embrace change like a long-lost lover, yet this constant change can t help but doom any project. Project X is due in 1 year, but management, due to encouragement from the XP team, spends that year changing its mind. Result: failure. And management is still changing its mind a day before launch.

In the real world it s called making your mind up, having a clue. Yet XP wants to stand all this on its head and encourage ever-changing directions and goals.

In the next chapter we look at XP from a people point of view and introduce what we like to call Extremo culture. Then for pretty much the rest of the book, we examine the circle of snakes in more detail.