Problems with Extreme Programming
Filed Under Issues, Iterative, Model, Process, Development, Software | Posted on December 20, 2007
Chances are, when you are speaking to people about a software project and mention some development model, somebody will refer to Extreme Programming very enthusiastically and encourage you to try it, promising some incredible experiences. However, there are some issues with Extreme Programming, and it would be good if people reviewed these issues before going ahead with using Extreme Programming as a software development solution.
1. XP has the approach where there is a de-emphasis on detailed design in the beginning. This is supposed to lead to a situation where you actually build for what is required rather than making a heavy system that cannot be tweaked to respond to user requirements. However, developers will treat this as an excuse for not doing the required design, not something that should be encouraged.
2. XP has the concept of reliance on refactoring and unit testing as inputs to create a design. However, in most cases, doing an activity such as object modeling has many advantages, and those are very helpful for making a project successful. XP does not countenance this sort of design activity.
3. 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.
4. If you have an existing development process that’s working well for you, stick with it. Don’t change just because XP is promised to be the new super-method.
5. There is a lot of dependence on the customer. You need to have a mature customer representative dedicated to your project who can represent the problem and work with you to figure out the best solution over iterations. A lot of direct customers don’t have the software experience to be comfortable with the idea of successive iterations getting closer to the desired solution (with many of the early iterations not having any great feature).
6. To setup an XP team you must work not only with very skilled but open-minded people: pair programming can be a problem if you don’t feel comfortable with your desk-mates.
7. Unstable Requirements: Proponents of Extreme Programming claim that by having the on-site customer request changes informally, the process becomes flexible, and saves the cost of formal overhead. Critics of XP claim this can lead to costly rework and project scope creep beyond what was previously agreed or funded.
8. Requirements are expressed as automated acceptance tests rather than specification documents. This is radically different from current practices and development teams struggle to be able to do this.
9. There is no Big Design Up Front. Most of the design activity takes place on the fly and incrementally, starting with “the simplest thing that could possibly work” and adding complexity only when it’s required by failing tests. Critics fear this would result in more re-design effort than only re-designing when requirements change.
10. XP is normally claimed to work with small teams of upto twelve people, and projects having people more than that can cause severe problems in getting XP to work effectively.
11. XP is all-or-nothing practise. You need to do all the steps of XP in the way that they are supposed to be done, or it all fails. This is difficult to do unless all the stakeholders are brought into the whole XP concept.
12. Unit tests are useful in everyday coding (not just in XP). However, as a safety net for test-first design and constant refactoring, they leave a critical area uncovered: design correctness. Because XP as a process does not involve getting a design spec reviewed by senior engineers, and instead places the emphasis on a constantly evolving design, this can be a high risk.
13. What sort of projects is XP not suitable for ? if the problem domain is well understood, and the requirements are not likely to change, then you should choose a process that places less emphasis on the ability to “chop and change” at any stage.
14. Communication not really so strong (especially written): XP makes a big issue about its core value of Communication. Unfortunately, XP also makes a big issue about not doing any documentation (or at least very little, or none at all). This seems very contradictory, since documentation is the only way you can have continuity in a project if people change.
Leave a Reply
