Extreme programming (XP) challenges the traditional approach to software design through paired programming, where developers write code together, and by encouraging customer participation during all stages of the development process. Many software developers have warmed to XP, but will it work in your shop? Maybe not.

XP doesn’t fulfill its promise. Its attraction is that it puts developers in control of the development process. That’s a “fantastic win,” says software consultant Pete McBreen, author of Questioning Extreme Programming (Addison-Wesley). “The problem is that you need an entrepreneurial, agile, or custom organization that can make decisions quickly,” says McBreen. “That’s where problems surface. The XP concept rests on the premise of the whole team being in one place so it can quickly answer developers’ questions.” Getting answers from a middle manager about a project’s requirements can keep everyone waiting, says McBreen.

Eight reasons to not implement XP
Software consultant Matt Stephens agrees. Stephens, who also edits the satirical Web site Software Reality, says XP’s main problems are:

1. De-emphasis on up-front design work
Developers sometimes take a myopic approach and fail to think ahead, but skipping analysis and design is a massive cop-out. When requirements change midproject, developers often think it’s because customers didn’t know what they wanted. However, analysts earn their money by walking customers through mock screen shots, storyboards, and use cases until the customers know what they want before a single line of code is written. It’s much cheaper and less risky than the XP approach.

2. Reliance on refactoring and unit testing to create a design
This is a mind-numbingly bad approach. Refactoring and unit testing have their places. For example, refactoring is useful for redoing badly written code, and it’s a good way to create a design from scratch. But programmers who take this questionable approach miss out on a lot of useful benefits that come from other approaches, such as up-front object modeling. XP’s answer, which is to do some modeling, doesn’t cut it.

3. Dependence upon optional scope contracts to circumvent the problem of not knowing what will be delivered until the last minute
Programmers can use “optional scope contracts” to goof off for six months and turn in a high-quality login screen at the end. The slightly naive defense from XP author Kent Beck (Extreme Programming Explained: Embrace Change) is that programmers won’t do this “because they want repeat business.” This is idealistic thinking.

4. Catching the inevitable bugs in a design created from refactoring with pair programming
Not everyone likes pair programming. It’s useful for tackling a particularly complex problem, but most of the time it’s overkill. Pair programming also hinders “pure” programming, where one highly tuned mind meditates on a problem to produce a clean design.

5. Use of on-site customer reps to avoid writing down requirements in permanent form
The on-site customer rep played a large part in the failure of the C3 project, the Chrysler project that was the XP flagship. When their key customer rep left the project, she took a lot of domain knowledge with her. (Story cards don’t count, as they cannot be easily backed up, e-mailed, and signed off.)

6. For most projects, XP is too minimal and too risky
XP is limited to chaotic projects that previously had no process. But then again, on such projects, anything would be an improvement.

7. XP is complex
Sure, the practices and values are simple, but in reality it takes a lot of concentration and effort to steer a “true” XP project. That’s time and effort better spent on less risky, more beneficial practices—such as writing things down.

8. XP relies on too many things
XP is a minimalist process that relies on a number of practices to make up for its lack of rigor in other areas. If something goes wrong, the whole project runs the risk of failure. All things considered, XP is a high-risk software process.

Good communication takes more than a room full of programmers
XP’s minimalism can lead to confusion, ambiguity, and forgotten requirements and design idioms. XP’s answer is to foster close communication by putting all the programmers in the same room, but this may not be sufficient except in the most trivial projects. Putting all your programmers in one room doesn’t guarantee they’ll communicate effectively.

XP can work in a development shop if both the development team and the business organization are realistic about what XP can deliver. That means more than putting everyone in the same room.

No XP for me

Have you implemented XP in your development shop? How did it go? Post a comment below, or drop us an e-mail.