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.