#2782

Agile and the Cost of Change Curve

Originally Extreme Programming suggested that the cost of change over the duration of a software project could be “flattened”.

“What if the cost of change didn’t rise exponentially over time, but rose much more slowly, eventually reaching an asymptote? … This is one of the premises of XP. It is the technical premise of XP. If the cost of change rose slowly over time, you would act completely differently from how you do under the assumption that costs rise exponentially.”
– Kent Beck, Extreme Programming Explained (1st edition, page 23)

This discussion is notably absent from the second edition of the book. I remember hearing Kent speak about this (at Agile 2007 I think). This was removed largely because of lack of data to back it up.

From a technical perspective flattening the cost of change seems plausible. Better languages, better tools and techniques and a better understanding of what constitutes a well designed piece of software all suggest that the

If this is true then the best agile can do is delay the inevitable.

Big Balls of Mud: Is This the Best that Agile Can Do?
– Brian Foote & Joseph Yoder

(for more detail see the original paper: The Big Ball of Mud)

Introducing Agile in the Very Large: Microsoft Developer Division’s Journey
– Sam Guckenheimer

(Slide deck is available online, registration required)