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.
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, 1 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