Does the Cost of Fixing Errors Curve Invalidate XP?

Does the "Cost of Fixing Errors" Curve Invalidate XP?

If this curve is still valid, does this mean XP is invalid? I argue that it is not. Several of the XP practices specifically ensure that the costs associated with this curve are kept minimal.

Unit testing and test-first design ensure that bugs are found quickly when they are cheap to fix.
On-site customer and functional testing ensure that the analysis and specification of the system are precise and up to date with business requirements.
Pair programming finds bugs quickly and spreads knowledge.
Refactoring and "once and only once" ensure that the system remains well designed and easy to change.
Regular releases gives regular customer feedback and forces the team to make the "release to production" and maintenance phases (where the cost of fixing errors rises dramatically) as cheap as possible.

Thus, XP attacks the roots of the high cost of fixing errors (with good specifications, good design, good implementation, and fast feedback). Furthermore, by using very short cycle times, the cost is never allowed to rise very high.

Not-So-Extreme Programming

Note that, with the exception of the very short cycle times and pair programming (which in XP replaces the inspections, design sessions, and training that are accepted in most methodologies), these practices are neither very original nor extreme.

Although errors are most costly to fix when found in later phases, each later phase is more likely to find errors in previous phases. This is because each phase produces a more concrete, more tangible , more testable output. Therefore, we need an iterative process that incorporates feedback to improve earlier work.

Iterative Versus Incremental

The well-known "waterfall" method is rarely used, even by those who claim (or are forced) to use it. Most development methods are incremental and iterative. What do those words mean?

Iterative— Repeating the same task to improve its output
Incremental— Dividing a task into small tasks , which are completed one by one (sequentially or in parallel)

Now let's see how different types of methods use iterations and increments .

Waterfall

Analyze, design, code, integrate, test—done! No iterations, no increments, no feedback; everything works the first time.

Classic RUP-Like Process

Analyze until 70-80% done. Start the design phase, but keep updating the analysis with any feedback you receive. Design until 70-80% done. Start the coding phase, but keep improving with feedback. And so on for the other phases.

This is an iterative process—feedback is used to improve the work done. The process is not incremental, except in the coding and integration phases, where some parts of the application may be delivered incrementally.

Incremental Architecture-Driven Process

Analyze the application until 70-80% done. Design the application so that the architecture and high-risk elements are relatively complete. Define functional groups. Refine the analysis and design as the project progresses.

For each functional group, a detailed analysis, a detailed design, coding, integration, and testing are done. Each increment is handled like a small RUP-like project, with iterations to improve the output. When the functional group is finished, it is delivered as an increment to the customer.

We have an iterative first step, which looks at the whole application. The application is then delivered incrementally, with each increment developed using an iterative process.

Extreme Programming

Gather an initial set of stories from the customers (high-level analysis). Define a metaphor (high-level analysis and design).

For each release, perform the planning game to allocate stories. For each story, define acceptance tests (analyze), write unit tests (design), code, refactor, integrate, test, and repeat frequently (iterate) until done.

The basic process is incremental on the level of releases and stories. Within those increments, the process iterates rapidly , based on feedback from acceptance and unit tests.

Buy on amazon.com >>

Marchesi M., Succi G., Wells D.

<< Previous page

Table of contents

Next page >>