The Art of Agile Development, 2nd Edition

CHAPTER FOURTEEN

Design

Software typically becomes more expensive to change over time.

I’m not aware of any good studies on this,¹ but I think it’s something every programmer has experienced. When starting a new codebase, we’re incredibly productive, but as time goes on, changes become more and more difficult.

That’s a problem for Agile. If change becomes significantly more expensive over time, the Agile model doesn’t make sense. Instead, the smart thing to do would be to make as many decisions as possible up front, when they’re the least expensive. In fact, that’s exactly what pre-Agile methods tried to do.

For Agile to work, the cost of change must be relatively flat, or even decreasing over time. Kent Beck discussed this in the first XP book:

[A flat cost of change curve] is one of the premises of XP. It is the technical premise of XP...If a flattened change cost curve makes XP possible, a steep change cost curve makes XP impossible. If change is ruinously expensive, you would be crazy to charge ahead without careful forethought. But if change stays cheap, the additional value and reduced risk of early concrete feedback outweighs the cost of early change. [Beck2000a] (ch. 5)

Extreme Programming Explained, 1st edition

But—as we’ve all experienced—the cost of change isn’t flat. It does increase over time. Does that mean that Agile teams are doomed to collapse under the weight of unmaintainable code?

The brilliance of XP was that it included practices to proactively reduce the ...