These error-prevention practices not only improve product quality, but also increase efficiency. Because errors are prevented, less debugging and rewriting is required, so the product gets completed faster.
Other advantages of XP include
- Its ability to accommodate the frequent changes and unexpected requirements that are so common in today's development environments.
- Its insistence on producing correct code and constantly integrating it into the application means that you almost always have a product to show customers. Moreover, if you always have a working version of the product, you can release the product the moment you decide it has the requisite functionality.
I've found that two main problems can occur with XP. First, if you are not working with excellent programmers and do not allow adequate time for refactoring, the code will lack a real internal structure. While well-structured code resembles a tree, XP code often resembles a pile of spaghetti. With no initial design phase, developers often end up writing code that cannot be extended to meet the needs of the project's later iterations. Moreover, if the process is not controlled, the developers might use XP as a cover for "happy hacking" and the program can end up looking like Frankenstein's monster. Most XP projects need to be rewritten in the later phases of the project to correct one or more of these structural problems.
The second problem is that XP can lead to extra work if it is applied in inappropriate situations. If you know the project's general scope upfront and choose XP to implement it, you might end up reworking the code more than you would if you had used a process that contained an initial design phase. Your estimations of required resources would also be less accurate with XP than they would be with more traditional development processes, because it's so difficult to make these estimations without a design that helps establish milestones and define project scope. Of course, if you cannot define your project's scope upfront because it is so new or dynamic, this is a necessary evil.
Rapid Application Development (RAD) Overview
Like XP, RAD is an iterative process that relies heavily on user involvement throughout the development process. This involvement begins during a true initial design phase—something that XP lacks. In RAD, the entire team (composed of about ten or fewer developers and users) meets at the beginning of the process to determine requirements and a fundamental project design. Of course, it's difficult to settle on requirements and a design without seeing and using the product, but much time can be wasted developing a product before the requirements and design have been agreed upon. RAD teams break out of this cycle by producing, reviewing, and refining a fundamental prototype during the design phase. Once project requirements are defined, the developers model the structure and interaction of the objects required to implement the requirements.
After the design is set and modeling is complete, the team implements the design in a series of iterations. Each iteration typically lasts several weeks, and implements the subset of features that the team agreed to implement for that iteration. The features implemented are almost always based on requirements set forth in the design phase; there is some flexibility for refining existing requirements and adding new ones, but only when the modifications will fit within original design. To ensure that the implementation is indeed rapid, the team uses CASE tools to model and generate the code. After one iteration is completed, the customer can use the product and, if necessary, suggest any necessary refinements. The next iteration will begin, then the team will continue cycling though iterations until the initial design has been completely implemented.