The Cost of Change Curve (aka the Cost to Fix Defects Curve)

Light Bulb  

XP puts the program into maintenance on the first day, and keeps it there forever. That s how we know XP produces maintainable code. ^[4]

It s been generally accepted for a long time that the further into a project, the more expensive it becomes to fix defects. If a design needs to be changed to accommodate new requirements, then similarly the cost is higher. In this section, we discuss the ways in which XP attempts to turn this cost of change curve on its head.

In Software Engineering Economics , Barry Boehm writes the following:

If a software requirements error is detected and corrected during the plans and requirements phase, its correction is a relatively simple matter of updating the requirements specification. If the same error is not corrected until the maintenance phase, the correction involves a much larger inventory of specifications, code, user and maintenance manuals, and training material.

Further, late corrections involve a much more formal change approval and control process, and a much more extensive activity to revalidate the correction. These factors combine to make the error typically 100 times more expensive to correct in the maintenance phase on large projects than in the requirements phase.

The total economic impact of leaving errors to be found after the software has become operational is actually much larger, because of the increased operational costs incurred by the error. ^[5]

In his 1999 IEEE Computer article Embracing Change with Extreme Programming, Kent Beck raises this question: What if we got good at reducing the costs of ongoing changes? This became generally accepted as gospel to the tune of XP reduces the cost of ongoing changes. (Note that many of XP s claims are actually made in WhatIf form.)

Boehm presents a logarithmic curve based on actual project data showing how cost increases from the requirements phase to the maintenance phase. Beck presents a what-if speculation that the curve could be flattened. And how does Beck propose to flatten the curve? By eliminating all of the low-cost places where requirements errors can be corrected, releasing software to the client almost immediately, and operating the entire project in maintenance mode ”the exact mode that Boehm s data shows to be the most expensive.

Have the Extremos ever provided any real data beyond what-if speculation? Well, generally, they ve pointed at C3. And guess what, this doesn t really make a very strong argument in their favor. What if it s still really expensive to skip requirements definition and up-front design and operate continually in maintenance mode?

SATIRE WARNING

Well, we d like to propose a few what-if speculations of our own (read the ^. notation as leads to ):

 

 WHATIF (CustomerBifurcation^.      GoalDonorAndGoldOwnerDisagreement)?     then ASSERT TerminationCanBeSuccess  WHATIF((SquadronOfOnsiteCustomers^.      CustomerDoesNotSpeakWithSingleVoice)&(OralDocumentation))^.     MassiveConfusionAboutRequirements?      then ASSERT ItsTheCustomersProblem  WHATIF(LackOfUpfrontDesign^.      ConstantRefactoringAfterProgramming)? then ASSERT RewritingCodeIsLotsOfFun WHATIF(ConstantRefactoringAfterProgramming^.      RefactoringInACircle^.      SoftwareIsNeverDone)? then ASSERT     GoodThingTheresPlentyOfSnacks 

^[4] Ron Jeffries posting to the newsgroup comp.software.extreme-programming, subject: Is XP Early Maintenance? October 19, 2001.

^[5] Barry W. Boehm, Software Engineering Economics (Upper Saddle River, NJ: Prentice Hall, 1982), pp. 39 “40.