n 1981, Barry Boehm published information on the cost of change in software at various stages of the development cycle. The following chart shows this cost curve: 
Boehm's Cost of Change Curve – 1981
This model has historically led the industry to believe that the most important thing we can do is “get the requirements right!”. The thing is, the model above is somewhat incorrect. It assumes a traditional software development lifecycle is the only way software is built and that working software can only be used at the end of a project. With the rise of agile development techniques this is no longer true and we can deliver usable software every week or two.
Also, from the chart, consider that bottom axis – time. Time here represents the length of the feedback cycle; i.e. how long it takes to realise a problem exists and that a change is needed. Time is the critical element in determining the cost of any change. The longer we go before realising we need a change, the higher the cost of that change.
In an agile approach, the short iterations of a few weeks or less result in a much shorter feedback cycle.
Scott Ambler published the following chart on the cost of change in relation to defect correction and the point in the development cycle where that defect is detected. Again, the longer the feedback cycle the higher the cost of rectifying the problem.
Image via Scott Ambler - http://www.ambysoft.com/essays/whyAgileWorksFeedback.html
So by using Scrum and putting in place good engineering practices alongside a short feedback cycle we establish a number of mechanisms that help us rapidly detect mistakes in both requirements and their implementation. This in turn allows us to take corrective action and fix the problem while it is still cost effective for us to do so.
In the end, this helps us keep our application quality high and provides better value to our end users and customers.
Have you read "The Leprechauns of Software Engineering" (https://leanpub.com/leprechauns)? In Chapter 10 this covers why the cost of change curve is a unsubstantiated claim derived from repetition and mutation of one original, shaky, study.
ReplyDeleteI think we (as an industry) needs to be more rigorous about the claims we make, particularly when they quickly achieve the status of fact through repeated blog posts etc.
I'm not saying that there is no difference in cost in fixing defects at different stages. However, given that there is no statistically valid data to support the extreme cost difference, we should be far more cautious about claiming benefits from particular methodologies.
P.S. I do believe that an Agile approach is better than Waterfall; we just need to be careful about how we justify the benefits.
@akash I haven't seen that book. I'll add it to my reading list. Thanks :-)
ReplyDelete