Rapid Application Development (RAD), Extreme Programming (XP), and the Personal Software Process (PSP) are three development processes often mentioned as the industry continues its quest for a development process that will help teams release better software faster. As I've said previously, it's impossible to say which process is "best" because different processes work better in some situations than in others. Moreover, no particular process can help you improve software reliability and reduce development time; this can only be achieved through error prevention, and error prevention can be incorporated into any development process.

Overview
XP assumes that requirements will change, so it makes no attempt to create and follow an initial design. Instead, the application is designed and developed incrementally in a series of brief design-coding-testing iterations. Each iteration begins with the team of ten or fewer developers and at least one user representative (the "customer") determining what features the upcoming one- to two-week iteration will implement. During each iteration's design phase, the user provides a list of "stories" they would like mplemented, the developer estimates the time required to implement each story, then the customer decides what to implement in the current iteration. The team then determines how to divide the work. During the implementation phase, developers often work in pairs: each pair writes unit tests before they code each unit; writes the unit with one developer typing and one developer watching for design flaws, algorithmic errors, and general coding problems; then verifies whether the unit is correct by running all relevant tests the team has accumulated. On a daily basis, each pair integrates their thoroughly tested code into the application.

At the end of each iteration, the customer has a working (though not full-featured) product to use. The customer provides feedback on the current iteration as the team begins the design phase for the next one. The new iteration might implement outstanding features requested for previous iterations, incorporate features that satisfy new business requirements, or refine existing features. After this iteration is planned, the process cycles through another round of implementation, testing, and feedback, then additional iterations are performed until the customer is satisfied with the product.

Pros
The main advantage of XP is that it is the most modern unintentional implementation of error prevention I've seen in the software industry. Studies have shown that code quality improves when XP is implemented, but do not explain the reason why. I propose that this improvement occurs because XP promotes error prevention in the following ways:

• By requiring developers to create unit test cases for each piece of code even before it is written, XP ensures that testing occurs throughout the development process, instead of just at the end. Early testing prevents bugs from spawning more bugs and becoming deeply embedded in the code. If you delay testing until the later stages of development, you will not only spend more time fixing each bug, but you will also have more bugs to find and fix.
• By requiring developers to build a large number of test cases and rerun the entire suite religiously, XP encourages test automation. Test automation reduces the risk of human error leading to false positives or overlooked errors. When you can quickly and easily replay the test suite, you can pinpoint and remove errors quickly, before other team members begin building upon the problematic code.
• By using pair programming, XP prompts developers to engage in perpetual code reviews. By requiring flexible and shareable code, it encourages developers to follow coding standards that steer them away from confusing and dangerous coding constructs. When code heeds proven coding guidelines, modifications are much less likely to introduce errors.

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.

Cons
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.Pros
RAD's main advantages stem from its insistence on a design phase. Because developers and customers agree on a design before implementation begins, developers are aware of the "big picture" while they are coding. They know how different units will work together, which in turn allows them to implement the product more elegantly and logically, as well as avoid a lot of the rewriting eventually required with XP. Having a design phase also helps the team estimate project deadlines and budgets. With RAD, the team always knows what the project will involve and what milestones must be met before the project is considered complete. With XP and other processes that lack a design phase, the best you can do is make short-term stimates at the beginning of each iteration.

Cons
RAD's main weakness is its lack of built-in error prevention practices, but this is not a true problem as long as you recognize this and compensate appropriately. A RAD process could potentially prevent errors as well as—or even better than—an XP process, but the error prevention must be consciously integrated into the RAD process, whereas it is innate in the XP process. If you fail to intentionally weave error prevention strategies such as unit testing, coding reviews, and coding standards into the development cycle, the lengthy and costly debugging process that will be required at the end of the project will negate the advantages gained by having a design phase.

In addition, if you use RAD for a project that is very dynamic or whose scope is difficult to imagine upfront, you are likely to encounter problems because RAD is not designed to accommodate the degree of change your project will probably require. The original features can be refined during the iterations, but RAD leaves little room for adding new features that do not fit into the original design. If your original design does not account for all necessary features, you either need to delay the implementation of these new features or start a new cycle. On the flip side, if you design and implement more (or different) features than you really need, you'll have done a lot of unnecessary design and implementation work.

Personal Software Process (PSP) Overview
PSP is not a software development process. Rather, it is a software process improvement methodology, developed by Watts Humphrey in 1989, that helps an individual developer write better code and plan projects more accurately. Matrices form the foundation for PSP. Developers take it upon themselves to track defects, code complexity, code size, progress towards project milestones, and other quantifiable metrics in matrices. As data accumulates, they analyze it to increase their awareness of their personal trends, then use it to develop customized checklists and other tools that help them improve their coding practices and better estimate project durations. For example, if a developer finds that 20 percent of his defects stem from errors within a particular type of coding construct, he could add to a code review checklist an item that reminded him to find and review all instances of this construct.

Typically, the developer creates a personal project plan and engages in design reviews during the design phase, tracks metrics, and performs code inspections throughout the implementation phase, then compares the actual results to the plan after the project is completed.Pros
The primary benefit of PSP is that it improves product quality and process efficiency. The custom reviews required at every point in the process ensure that design and coding problems are identified as soon as possible. This is beneficial because when a problem is allowed to remain in the code, other design or coding elements interact with it, more errors occur, and more time and effort are required to remedy what probably began as a simple problem.

Moreover, PSP typically results in fewer missed deadlines for two main reasons. First, by requiring developers to track current metrics against historical progress data, it helps developers estimate how much time different phases and tasks will require. Second, because it prevents errors, developers that practice PSP are typically free from the last-minute debugging crises that typically delay projects when developers ignore errors until the end of the project.

Cons
The main problem with PSP is that learning and practicing it are usually labor-intensive. A 100 percent by-the-book implementation takes months, and manually recording and calculating the various metrics requires a significant investment of developer time. Fortunately, many of the processes can be automated to mitigate the labor involved. With a combination of scripts and automatic error-prevention and static-analysis tools,¹ you can automatically calculate and track size metrics as well as automate most of the required reviews. If you have a way to enforce personal coding rules and make custom measurements, you should be able to automate all PSP steps required for the implementation phase. Design practices, such as estimation and reviews, must still be performed manually and require a decent degree of developer commitment.

The other caveat with PSP is that it is not actually a software development process. It offers practices that can improve the design and implementation phases of any development process, but does not attempt to define how a product should be designed and implemented. PSP needs to be implemented in conjunction with a structured development process.

Designing a Development Process that Works for You
I recommend that you do not choose a development process, but rather create a customized development process that blends whatever elements of XP, RAD, PSP, and other development processes suit your project and goals. Many evangelists for different processes insist that their favorite development process must be implemented completely or not implemented at all. I have found that this approach is overly restrictive and counterproductive. I suggest that you take a look at the possible choices, then pick and choose as appropriate. By building a custom process in this manner, you can take advantage of the different processes' pros, and mitigate their cons.

Determine whether or not you can define the scope of your project at the beginning of the process. If your project is so unprecedented or dynamic that even a fundamental design phase does not make sense, we recommend that you start with XP. When you are trying to flesh out the product, it will be helpful to have the support of XP's frequent customer feedback and rapid release cycles; this way, you can easily gauge the success of a new idea before you invest too much time and effort in it. If you are really concerned about producing high-quality code and having minimal debugging, I recommend that you integrate PSP practices into the XP structure. As developers watch one another code during pair programming, they can work together to identify and avoid their most common coding mistakes.

At some point within the XP process, the code typically grows so unstructured or unscalable (or both) that you need to rewrite it. At this point, it makes sense to use a RAD-like process for the redesign. The main RAD component that will help you here is its design phase. Start with a design phase in which you determine how to reimplement the existing product's features, then develop a plan for reimplementing the product iteration by iteration. You can decide whether to use other elements of RAD, such as CASE tools, by considering their benefits and drawbacks on a project-by-project basis.

If you can produce at least a basic design at the beginning of your project, we recommend that you start with RAD, then build into it the most useful practices from XP. For example, you could build into the implementation phase practices such as code reviews, coding standard enforcement, and unit testing. You could also rearrange the development team's work area in such a way that permits developers to engage in pair programming for problem solving and challenging implementation tasks. To further your error-prevention efforts, you could integrate PSP into the process to help developers recognize and prevent their most common coding mistakes.

In my opinion, the key to improving software reliability and reducing development time is not following any particular process, but rather ensuring that your process suits your project and includes practices that aggressively prevent errors. Each error you prevent translates to not just one fewer bug that you need to find and remove later in the project's lifecycle, but hundreds. The more effectively you prevent errors during the development process, the sooner you will be able to release reliable products.

¹Error-prevention and static-analysis tools mentioned in the article are developed by Parasoft.