In this article, Adam Kolawa provides a quick overview of RAD, XP, and PSP, covers the main pros and cons of each process, then explores how these processes might be combined in a complementary manner to suit different development needs.
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.
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.
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.